On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand <k...@gentoo.org> wrote:
> A draft of a Pre-GLEP for the Security project is available for > reading at https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security > > The GLEP follows a line of GLEPs for special projects that have > tree-wide access in order to ensure proper accountability (c.f GLEP 48 > for QA and still non-produced GLEP for ComRel (I've started working on > this and will be presenting this one later as current ComRel Lead)) > > Comments, patches, threats, etc welcome > Most of it seems more appropriate for a project page to me and up to the sec. team, so I'll comment on the global parts only. The only global part I see is the "Security package version/revision bumps and package masks". This one would benefit from a proper definition of the rules here: If severity is X then inactive is defined to be Y days. After that, sec. team can fix themselves. It should also be the same for masking: If severity is X and no fix is known after Y days/months then sec. team should mask it (but not last rite it, this should still be maintainer/treecleaners). I think the delay should be clearly stated in the bug with something like: Please keep in mind that since this is a remote code execution vulnerability, security team will take action if nothing happens within one week. If you have tools filling the severity fields then a proper definition allows to automate this too. My point here is to avoid having all the responsibility falling under the lead but focus more on getting things done and educating fellow developers: Lower delays for more serious bugs will make people understand and prioritize better the issues at hand and their implications. Also, it'd be nice to have something more formal for sec. cleanup: "After 30 days a sec. issue has been fixed, sec. team is free to cleanup old vulnerable versions.". I've seen too much pings by sec. team members on old bugs for this and they could have spent the same amount of time simply doing it instead. Alexis.
