Gentoo Archives: gentoo-project

From: Kristian Fiskerstrand <k_f@g.o>
To: gentoo-project <gentoo-project@l.g.o>
Subject: [gentoo-project] Re: [pre-glep] Security Project Structure
Date: Tue, 04 Dec 2018 21:05:48
Message-Id: 1d3c9d30-5570-de92-3da9-75bd33c02075@gentoo.org
In Reply to: [gentoo-project] [pre-glep] Security Project Structure by Kristian Fiskerstrand
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

Attachments

File name MIME type
signature.asc application/pgp-signature

Replies