1 |
Hi Kristian, |
2 |
|
3 |
On Sat, 11 Mar 2017 21:50:51 +0100 Kristian Fiskerstrand wrote: |
4 |
> A draft of a Pre-GLEP for the Security project is available for reading |
5 |
> 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 |
First of all, thank you for this Pre-GLEP, since we really need some |
15 |
public and established policy for the Security project. |
16 |
|
17 |
1. From this proposal it looks like the Security Project Lead |
18 |
obtains a lot of power and a lot of responsibility, maybe too much |
19 |
for a single person to handle. |
20 |
|
21 |
While the Deputy may be assigned, this still gives all power to |
22 |
single hands. Maybe it will be better to establish something like |
23 |
the Security Project Council (SPC)? E.g. three project members may |
24 |
be elected to this SPC, so that all serious decisions will require |
25 |
some team agreement from at least 2 SPC members. This way the |
26 |
Deputy will not be needed as well. |
27 |
|
28 |
2. "If a vulnerability is unlikely to be fixed by upstream or the |
29 |
package's maintainer it might require a package mask." — I'd like |
30 |
to see this expanded to more detail, because it is possible to mask |
31 |
for removal and to simply mask without scheduled removal. |
32 |
|
33 |
Sometimes an application is desirable even if it is vulnerable, |
34 |
e.g. if there are no alternatives. Sometimes a vulnerability is |
35 |
minor or affect a very rare use case. Sometimes users need a |
36 |
specific software version for their workflow and they don't really |
37 |
care about security — this affects many scientific packages being |
38 |
used at isolated HPC setups. |
39 |
|
40 |
My point is that users must be informed about security problem, but |
41 |
they still should have a choice. So it should be either a rule |
42 |
"mask without removal" or clear guidelines when to remove a |
43 |
package and when to not. |
44 |
|
45 |
Best regards, |
46 |
Andrew Savchenko |