Gentoo Archives: gentoo-dev

From: Thomas Deutschmann <whissi@g.o>
To: gentoo development <gentoo-dev@l.g.o>
Cc: Gentoo Security <security@g.o>
Subject: [gentoo-dev] Re: RFC: Pre-GLEP: Security Project
Date: Mon, 13 Mar 2017 19:02:16
Message-Id: bb3da6e1-670c-c73b-36fa-fd1ba7a9bd47@gentoo.org
In Reply to: [gentoo-dev] RFC: Pre-GLEP: Security Project by Kristian Fiskerstrand
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

Attachments

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