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