Re: [gentoo-dev] RFC: Pre-GLEP: Security Project

[Kristian Fiskerstrand]

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