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

[Alexis Ballier]

On Sun, 12 Mar 2017 19:59:11 +0100
Kristian Fiskerstrand <k_f@g.o> wrote:

> 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.


To me, this is the only thing that is *not* internal here.

You have a target delay X. What happens after X expires ? After 2X ?
10X ? When is it right for sec. team to intervene ? When is it right
for sec. team to intervene after maintainer has asked for a delay ? When
is it right for sec. team to intervene against maintainer wishes ?

I'm pretty sure you have a good idea of when sec. team should act, and
you're right in the sense that severity analysis does not belong to the
GLEP, but something referencing your treatment policy and explicitly
stating in the GLEP that (any member of) sec. team is allowed to take
action after some multiple (possibly one) of the target delay would be
more clear and avoid entirely having the lead to take a decision every
time.

I'm insisting here for various reasons:
- It is preferable to have a clear resolution procedure, known in
  advance, instead of something at someone's discretion that happens
  to be brought up every time some other one is not happy.
- Sometimes sec. masking will be controversial (nethack maybe?), having
  the lead take all the hate is not fair either.
- I would definitely prefer saying about Gentoo: "We do not ship
  anything that has had a CVE reported for more than a month" than "We
  do our best to keep your system safe".


Also, please keep in mind that for most people A4/A3/B3/B4/etc. are
paper sizes :) (so that restating the delay in sec bugs is not wasted
electrons)


[...]
> > 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.

Well, I'm not saying the maintainer should not nor that sec. team must
do it themselves, I'm just saying that sec. team can. There are
complex cases but the vast majority of security cleanups are no
brainers that anyone who has passed the quizzes can do.

Alexis.