On 03/12/2017 09:14 AM, Alexis Ballier wrote: > 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).
The severity levels and timelines are already defined in the referenced vulnerability treatment policy. We might be able to incorporate this suggestion by stronger reference to that for timeline, but in the end that should be the internal policy anyways. In general I would prefer the GLSA to be more higher level as we know things are going to need to be updated from time to time on these matters. > > 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. The lead sets policies and is responsible for keeping vulnerability treatment policy and other documentation up to date c.f Documentation of process The Project shall have procedures in place to document its process and regularly update the documentation including the Vulnerability Treatment Policies[3]. ^^ which was intended to cover some of these concerns > > > 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. This presumes all security members are gentoo developers with tree access and can do it themselves, but I'm not convinced cleanups are vital enough for security to interact as it requires quite a bit of work for an unfamiliar package to know which files to remove in files/ for specific versions and/or other package-specific quirks. The package maintainers really should be able to handle this or hand off the package to someone else. -- Kristian Fiskerstrand OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
signature.asc
Description: OpenPGP digital signature
