1 |
On 12/4/18 9:55 PM, Kristian Fiskerstrand wrote: |
2 |
|
3 |
> security_project-structure.rst |
4 |
> |
5 |
> Abstract ======== |
6 |
> |
7 |
> This GLEP outlines the abilities and purpose of the Gentoo Security |
8 |
> Project. |
9 |
> |
10 |
> Motivation ========== |
11 |
> |
12 |
> The Gentoo Security Project is the public liaison between Gentoo or |
13 |
> external users and Gentoo developers in any security-related field. |
14 |
> The project's mission is to ensure that each known threat in software |
15 |
> packaged in the stable ebuild repository (stable tree) is fixed in a |
16 |
> timely manner, thus ensuring that users in the stable version of |
17 |
> Gentoo receive quality and secure software. |
18 |
> |
19 |
> After considerable events regarding security in Gentoo Linux, like |
20 |
> SPARC[#SPARC_REMOV]_ and HPPA [#HPPA_REMOV]_ removal from the |
21 |
> "supported" security architectures, it has become quite obvious that |
22 |
> the current policy regarding "supported" and "not supported" |
23 |
> architectures is not capable of address the most important security |
24 |
> factor, which is to ensure that end-users are protected from |
25 |
> malicious/vulnerable packages in the stable tree. |
26 |
> |
27 |
> This is so because the Gentoo Security Project does not have a proper |
28 |
> control nor is empowered to ensure that packages inside the stable |
29 |
> branch of Gentoo Linux official ebuild repository are secure and can |
30 |
> be fixed in a timely manner. Especially if a threat is published or |
31 |
> disclosed by the security groups in which Gentoo Security Project has |
32 |
> participation. |
33 |
> |
34 |
> The current policy of having a "supported" list of architectures does |
35 |
> not work directly towards the objective of the Security project, |
36 |
> instead, it only allows the project to recognize some architectures |
37 |
> as "not supported" and don't be obligated to release a GLSA for that |
38 |
> specific architecture when an issue arises. |
39 |
|
40 |
|
41 |
I personally don't agree with part of this section; security is |
42 |
relative, and if it is stated to not be supported there are no security |
43 |
assumptions. If anything the removal of these arches as security |
44 |
supported demonstrates an active decisions not to support them, and |
45 |
signals to users of these arches that they can't depend on security |
46 |
information from Gentoo. Stable generally means a stable tree of |
47 |
dependencies, without security assumptions, if this is e.g used in a |
48 |
closed lab that likely doesn't impact much. |
49 |
|
50 |
So comments welcome |
51 |
|
52 |
> |
53 |
> |
54 |
> Specification ============= |
55 |
> |
56 |
> The Security Project's purpose is to ensure users in the stable |
57 |
> category of Gentoo are provided with applications that to the best of |
58 |
> the knowledge of the Gentoo Developers are free of vulnerabilities. |
59 |
> In order to achieve this purpose, the Security Project require |
60 |
> certain abilities and responsibilities as outlined in this GLEP in |
61 |
> order to ensure the best interests of all users. |
62 |
> |
63 |
> Security Project Lead |
64 |
|
65 |
Since the security project is moving into tree wide territory here, the |
66 |
following used to contain a section similar to GLEP 48 on council |
67 |
approval of leads, but that was removed in a later revision, so we |
68 |
welcome comments on the topic. Comments welcome. |
69 |
|
70 |
> --------------------- |
71 |
> |
72 |
> * The Security Project is required to have at least one Security |
73 |
> Project Lead. * The Security Project Lead is chosen at least yearly |
74 |
> by private or public election among the members of the Security |
75 |
> Project. * The Security Project Lead's term expires one year after |
76 |
> the voting is concluded. If the time expires the current Project Lead |
77 |
> retains the position until the security team can have another |
78 |
> election. In the case of Lead's definitive absence, the Security |
79 |
> Project must start the election process in a timely manner. * The |
80 |
> Security Project Lead can choose one member as a Deputy in case of |
81 |
> only one Lead. The Deputy has all of its powers directly delegated |
82 |
> from the Security Project Lead and thus the Deputy's actions and |
83 |
> decisions should be considered equal to those of the Security Project |
84 |
> Lead. * The Deputy is directly responsible to the Security Project |
85 |
> Lead and its actions reflects upon the Security Project Lead. |
86 |
> |
87 |
> Joining the Project ------------------- |
88 |
|
89 |
|
90 |
For some reason, the following section on removal from the project |
91 |
received significant interest and as such became quite specific. |
92 |
|
93 |
> Removal from Project -------------------- |
94 |
No futher immediate comments, please see initial email |
95 |
|
96 |
EOF |
97 |
|
98 |
-- |
99 |
Kristian Fiskerstrand |
100 |
OpenPGP keyblock reachable at hkp://pool.sks-keyservers.net |
101 |
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3 |