1 |
Gentoo Security Project Summary |
2 |
|
3 |
Short Summary: |
4 |
The Security Team is up and running, but we are dealing with numerous |
5 |
tasks and a high load in daily maintenance. Fresh blood is not only |
6 |
appreciated, but needed to continue the luxury of Security Support we |
7 |
currently have. We have too many open bugs, too many undrafted GLSAs |
8 |
that are eventually sent too slow, and a lot of channels to monitor. |
9 |
There are some bugs that need extensive amount of work to be resolved. |
10 |
The Security Team is also developing applications to support our |
11 |
workflow and user's systems, such as improvements to glsa-check and our |
12 |
DTD, a new Ruby on Rails application to draft GLSAs and an application |
13 |
to coordinate Kernel security support and check local systems. |
14 |
|
15 |
== Personal changes == |
16 |
|
17 |
=== Lead Election === |
18 |
|
19 |
Since the last election had been longer than a year ago, we held a new |
20 |
election during the first two weeks of May. It was determined |
21 |
unanimously that Pierre-Yves Rofes (py) and Robert Buchholz (rbu) will |
22 |
be the new French-German duo that is our Team Leads. We would like to |
23 |
publicly thank Raphael Marichez (falco) and Matthias Geerdsen (vorlon) |
24 |
for doing the job the years past. They were both not available for |
25 |
another term. |
26 |
|
27 |
=== Additions to the team === |
28 |
|
29 |
Alex Legler (a3li) recently joined the Security Team. However we still |
30 |
need more people helping with the daily maintenance work. This call for |
31 |
help applies to both developers and users. |
32 |
|
33 |
For more details on how to join the Security team, see: |
34 |
http://www.gentoo.org/proj/en/security/ |
35 |
|
36 |
Or, more specifically: |
37 |
http://www.gentoo.org/security/en/padawans.xml |
38 |
http://www.gentoo.org/security/en/coordinator_guide.xml |
39 |
http://www.gentoo.org/security/en/vulnerability-policy.xml |
40 |
http://www.gentoo.org/security/en/bug-searching.xml |
41 |
|
42 |
== Maintenance == |
43 |
|
44 |
=== Bugs and GLSAs === |
45 |
|
46 |
We have reached new highs in the number of open bugs and the length it |
47 |
takes all of us to resolve them. A shortness in Gentoo developers in |
48 |
general and on our team is leading to three issues: |
49 |
|
50 |
(1) Security bugs are not resolved by ebuild maintainers |
51 |
|
52 |
Some security bumps are staying open for weeks with teams not responding |
53 |
to pings. Even issues that could be resolved before being public (what |
54 |
we call "embargoed bugs") are not resolved due to maintainers not being |
55 |
responsive on such bugs. |
56 |
In fairness, I have to note this is limited to only some herds and not |
57 |
architectures. Architectures and in particular their Arch Security |
58 |
Liaisons are doing their job in a reliable and timely fashion. |
59 |
|
60 |
(2) GLSAs are delayed |
61 |
|
62 |
We're slow! We are sorry. I feel this is a great disappointment |
63 |
especially in those cases where maintainers and arch teams are doing a |
64 |
fast job and we take 4 weeks to write the accompanying GLSA. I see |
65 |
potential for improvement with the GLSAMaker rewrite described below. |
66 |
Contributors to GLSA writing are greatly welcome. |
67 |
|
68 |
(3) Security Team is not resolving bugs either |
69 |
|
70 |
In the past, we have been conducting simple version bumps ourselves or |
71 |
have masked vulnerable ebuilds. Currently, doing other people's jobs in |
72 |
the security process is mostly on hold as we have a hard time struggling |
73 |
to cope with our part of the job. |
74 |
|
75 |
|
76 |
=== Documentation update === |
77 |
|
78 |
We actually updated our existing documentation to reflect more of our |
79 |
security process. Isn't that awesome? Read our project pages to find out |
80 |
more: |
81 |
http://www.gentoo.org/proj/en/security/ |
82 |
|
83 |
|
84 |
=== GLSA dtd and glsa-check === |
85 |
|
86 |
We have been discussing changes to the GLSA DTD for ages now. There's |
87 |
few people interested in the subject and I have been slacking on it. I |
88 |
have picked up glsa-check maintenance recently and we will announce |
89 |
changes to the DTD to the dev lists as soon as they are fully drafted. |
90 |
Since the GLSA format is supported in all package managers, the change |
91 |
will be announced at least 6 weeks before going live. |
92 |
|
93 |
Oh, and glsa-check will see some bugs fixed, I hope. And support for |
94 |
UTF-8. And support for mask-glsas. Hmm.. anyone else here to help? |
95 |
|
96 |
glsa-check changes in 0.2.4: |
97 |
http://sources.gentoo.org/viewcvs.py/gentoolkit/branches/gentoolkit-0.2.4/src/glsa-check/ |
98 |
glsa-check changes in trunk (0.3): |
99 |
http://sources.gentoo.org/viewcvs.py/gentoolkit/trunk/gentoolkit/ |
100 |
New DTD proposals: |
101 |
http://git.goodpoint.de/?p=glsa-check.git;a=tree;h=refs/heads/glsa-2 |
102 |
|
103 |
|
104 |
== Feature extensions == |
105 |
|
106 |
=== GLSAMaker === |
107 |
|
108 |
The GLSAMaker is a web application that we use to draft, comment on and |
109 |
refine GLSAs. It allows for the export of the GLSA texts and XML files |
110 |
you might know from gentoo-announce or /usr/portage/metadata/glsa. The |
111 |
application is considered helpful by all of us, however its shortcomings |
112 |
require to duplicate some work that could be automated and its usability |
113 |
makes working with it less fun than it could be and slows our work down |
114 |
quite a bit. |
115 |
|
116 |
Alex Legler (a3li) and Pierre-Yves Rofes (p-y) are currently working on |
117 |
a rewrite that covers the current functionality and extensions to ease |
118 |
the workflow dramatically by integrating metadata from Portage, |
119 |
Bugzilla, the CVE database and Secunia. |
120 |
|
121 |
We are looking forward to GLSAMaker 2 becoming the central point for |
122 |
coordinating our efforts. |
123 |
|
124 |
A refined access control will allow us to give access to the tool to |
125 |
people that are not (yet) members of the team, and this allows us to |
126 |
accept contributions from the community and other developers that want |
127 |
to push GLSAs for their packages through our system faster. |
128 |
|
129 |
If you are into Ruby On Rails development, or are looking for a project |
130 |
to start, your help is greatly appreciated. |
131 |
You can follow development here: |
132 |
http://git.overlays.gentoo.org/gitweb/?p=proj/glsamaker.git |
133 |
https://redmine.stingray.a3li.info/projects/show/glsamaker2 |
134 |
|
135 |
|
136 |
=== Kernel Security === |
137 |
|
138 |
Since 2005, we are not issueing GLSAs for Kernel vulnerabilities which |
139 |
is an unfortunate flaw in our Vulnerability Policy. This is related to |
140 |
the fact that these vulnerabilities are extremely hard to track and we |
141 |
have a lot of Kernel sources with several maintainers. Unlike other |
142 |
projects, the Kernel is actively maintained upstream and by bumping to |
143 |
newer versions you will fix vulnerabilities automatically. This way, our |
144 |
ebuilds are staying secure even without GLSAs. You machines, however, |
145 |
may not. |
146 |
|
147 |
However, we are looking to improve the process of handling these issues |
148 |
as well. We are currently tracking all known bugs in Bugzilla, building |
149 |
a large database of Kernel vulnerabilities -- most of which are fixed in |
150 |
gentoo-sources. At the same time we are working on a tool to export this |
151 |
data into a format that could be distributed as part of the Portage |
152 |
tree. A tool will then allow checking of the locally running kernel |
153 |
version against the vulnerability data to determine which updates are |
154 |
required. |
155 |
|
156 |
This work is conducted by Björn Tropf (asyme) and Robert Buchholz (rbu). |
157 |
The part concerning the Portage tree will be proposed to this list at a |
158 |
later time when we have a working module to collect and evaluate the |
159 |
data. |
160 |
|
161 |
Follow our work here: |
162 |
http://git.overlays.gentoo.org/gitweb/?p=proj/kernel-check.git |