1 |
Hi, |
2 |
|
3 |
I am quoting <https://wiki.gentoo.org/wiki/User:K_f/GLEP:Security>: |
4 |
|
5 |
> == Abstract == |
6 |
> This GLEP outlines the purpose, responsibilities and abilities of the |
7 |
> Gentoo Security Project. |
8 |
> |
9 |
> == Motivation == |
10 |
> This GLEP aims to document the processes of the Security Project and |
11 |
> enpowering the project to operate on a wide scale across the Gentoo |
12 |
> tree, within the structure provided by this GLEP. |
13 |
|
14 |
I disagree with that. It looks like this GLEP was formed on base of |
15 |
GLEP:48 [1] but I think this is wrong (like I would withdraw GLEP:48 now |
16 |
that I read it). |
17 |
|
18 |
For example, the purpose and the process of a project shouldn't be part |
19 |
of any GLEP. These are project internal details and every project is |
20 |
free to change its process without a new GLEP approval. |
21 |
|
22 |
Also, for me the draft goes completely in the wrong direction. |
23 |
|
24 |
I would get rid of the entire "Security Project Lead" and "Joining the |
25 |
Project" paragraph: |
26 |
|
27 |
Gentoo security project is a project like any other Gentoo project: The |
28 |
team should decide in regular meetings how they want to do things. The |
29 |
team is encouraged to elect a lead each year like any other project is |
30 |
encouraged to do. In case of tied votes, the vote of the current lead |
31 |
will be counting twice to get a decision but this isn't special so we |
32 |
don't need to write it down for the security project. |
33 |
|
34 |
Because project lead may change each year, the absolute majority of the |
35 |
whole team must accept new members. Otherwise, the new project lead |
36 |
would be responsible for people who maybe in the project just because |
37 |
the previous lead liked them but he/she maybe don't trust them. But |
38 |
again, this is something the project would decide and shouldn't be |
39 |
handled in a GLEP. |
40 |
|
41 |
|
42 |
The "Security package version/revision bumps and package masks" looks |
43 |
relevant because it defines the "power" of the project: |
44 |
|
45 |
> * The Security Project does not want to override the maintainer's |
46 |
> autonomy, but if inactive might be required to fix a security |
47 |
> vulnerability by means of version bump or application of a patch in |
48 |
> a revision bump. |
49 |
|
50 |
I am not sure about this point. I am not aware of any GLEP/rule |
51 |
disallowing devs to touch packages of any other devs. When I did my |
52 |
quizzes I learned that you should have good reasons to do so and that |
53 |
you are responsible for any breakage. In other words: Only do that after |
54 |
you tried to contact the package maintainer (create a bug, |
55 |
write an email, try to talk to the maintainer/project in IRC...) but did |
56 |
not get a reply in time and always respect maintainer's coding |
57 |
preferences (i.e. don't rewrite the whole ebuild because you would do |
58 |
things differently when you just wanted to add a small patch fixing a |
59 |
build issue). |
60 |
|
61 |
In other words: Everyone is allowed to bump a package so we don't need |
62 |
to write down that security project is allowed to do that as well. |
63 |
|
64 |
It is different for QA project because QA members maybe rewrite a whole |
65 |
ebuild and ignore maintainer's preferences for project goals. |
66 |
|
67 |
|
68 |
> * If a vulnerability is unlikely to be fixed by upstream or the |
69 |
> package's maintainer it might require a package mask. Such mask |
70 |
> should never break the stable dependency tree. |
71 |
|
72 |
From my understanding the intention of this point is to make clear that |
73 |
security project members are allowed to remove an ebuild/package for |
74 |
ARCH users. |
75 |
|
76 |
I would get rid of the "such mask should never break stable dependency |
77 |
tree" because this a general rule. However, sometimes this might be |
78 |
required: Imagine an application (app-misc/awesome) which still depends |
79 |
on dev-lang/openssl-0.9.8 or any other ancient version of a dev-lang/* |
80 |
package. The application itself is fine and working but no one is |
81 |
providing an update to work with newer dependencies. |
82 |
Now the dependencies are EOL and a vulnerability was discovered. Because |
83 |
everything else has already migrated to a newer version no one is |
84 |
providing a patch. To get stable tree clean we would have to apply a |
85 |
package.mask. This would break the stable dependency tree so we would |
86 |
also need to take action against app-misc/awesome. |
87 |
|
88 |
This is something we should write down so everyone knows that the |
89 |
Gentoo security project has this power. |
90 |
|
91 |
|
92 |
> * These actions, performed on behalf of the Security Project, should |
93 |
> only be used if the Project finds it is in the best interest of |
94 |
> users and fellow developers to have the issue addressed as soon as |
95 |
> possible. Such action needs to be approved by the Security Project |
96 |
> Lead (or if a Deputy is appointed; the Deputy) |
97 |
|
98 |
This should be removed because this doesn't belong into a GLEP. That's |
99 |
how the project internally works. And if the team decide to change |
100 |
how it handle things this shouldn't require a new GLEP. |
101 |
|
102 |
|
103 |
"Subscription to security lists and acting on behalf of Gentoo", |
104 |
"Auditing and public reporting of issues in the name of Gentoo", |
105 |
"Embargoed lists" and "CVE Numbering Authority (CNA) status" don't |
106 |
belong into a GLEP. This is about the project's internal organization. |
107 |
|
108 |
|
109 |
See also: |
110 |
========= |
111 |
[1] https://wiki.gentoo.org/wiki/GLEP:48 |
112 |
|
113 |
|
114 |
-- |
115 |
Regards, |
116 |
Thomas |