1 |
This is the summary of the IRC meeting the Gentoo Linux Security Team had on |
2 |
Monday, March 20, 20:00 UTC in #gentoo-security (freenode). |
3 |
A raw IRC log of the meeting can be found here: |
4 |
http://dev.gentoo.org/~dercorny/security/sec-meeting-20060320.log |
5 |
|
6 |
|
7 |
Agenda was: |
8 |
----------- |
9 |
|
10 |
1/ Project status |
11 |
a) GLSA team status |
12 |
b) Kernel team status |
13 |
c) Audit team status |
14 |
|
15 |
2/ Improvements areas |
16 |
a) Maintainers involvement |
17 |
b) Recruitment |
18 |
c) Portage integration |
19 |
d) Other process or policy improvements |
20 |
|
21 |
3/ Lead(s) election |
22 |
|
23 |
4/ Public Q&A |
24 |
|
25 |
|
26 |
|
27 |
1/ Project status: |
28 |
------------------ |
29 |
|
30 |
a) GLSA team status |
31 |
|
32 |
The number of late GLSAs (means not delivered within the timeframe given by the |
33 |
policy) drastically increased by almost 50% [1]. Two main causes have been |
34 |
identified: |
35 |
- The GLSA team is operating close or below to the critical mass of GLSA |
36 |
coordinators, which causes delays in certain areas like GLSA voting, drafting |
37 |
and reviewing. |
38 |
- Package maintainer security awareness is bad: sometimes maintainers don't |
39 |
care about security, don't fix bugs in time, don't respond or are completely |
40 |
missing. This causes huge delays in the GLSA processing. |
41 |
Possible methods to resolve these issues are discussed in "Improvements areas". |
42 |
|
43 |
[1] http://dev.gentoo.org/~koon/arch_ratings.png |
44 |
|
45 |
|
46 |
b) Kernel team status |
47 |
|
48 |
Just as the GLSA team, the kernel team lacks the sufficient amount of manpower |
49 |
needed to operate as wished. As a result, the KISS project (a system designed |
50 |
to release kernel security advisories), originally thought to go live by 2005, |
51 |
still isn't ready for production use since the manpower to keep it fully |
52 |
updated is lacking. Although KISS is closely tied to the kernel work, a scout |
53 |
and a coordinator, who help finding and handling kernel bugs, are needed to |
54 |
fully implement it. Besides that, a draft of the kernel security policy [2] |
55 |
has been presented, which is expected to reduce the workload for the |
56 |
kernel team while improving the general enduser kernel security awareness. |
57 |
|
58 |
[2] http://dev.gentoo.org/~johnm/files/kernel-security-policy.txt |
59 |
|
60 |
|
61 |
c) Audit team status |
62 |
|
63 |
The overall status of the audit team isn't too bad. Altough the majority of the |
64 |
audit team is quite busy with non-gentoo stuff or inactive, a nice list of high |
65 |
profile security vulnerabilities was discovered. New developers and better |
66 |
coordination within the team could help to improve the speed of the audit |
67 |
project, so that bugs get dealt with faster. |
68 |
|
69 |
|
70 |
|
71 |
|
72 |
2/ Improvement areas: |
73 |
--------------------- |
74 |
|
75 |
a) Maintainers involvement |
76 |
|
77 |
Increasing the security awareness of maintainers is vital to the success of the |
78 |
Gentoo Linux Security Team. Unfortunately, missing or inactive maintainers are a |
79 |
general Gentoo problem. The security team can't deal with that alone because it |
80 |
has no means to punish bad maintainers, thus this has to be brought to the |
81 |
Gentoo council. A powerful QA team could improve the situation by cleaning out |
82 |
unmaintained packages or taking over if a maintainer doesn't reply in timely |
83 |
manner, but this will require changes in the QA policy which are still being |
84 |
discussed. |
85 |
|
86 |
|
87 |
b) Recruitment |
88 |
|
89 |
As mentioned in the status reports above, every team badly needs more |
90 |
developers. Since a lot of recruits drop out during recruitement or vanish after |
91 |
becoming a new developer, it was decided to rethink the recruitement process. |
92 |
The Security Team will now start to actively look for new members, for example |
93 |
by writing an article within the GWN. Also recruits should get more attention |
94 |
of senior developers, so that they feel involved and learn faster. The progress |
95 |
of the recruits should be followed closely, so that they can be upgraded |
96 |
appropriate to their skills, additionally more documentation will be written, |
97 |
for example about GLSAmaker. |
98 |
|
99 |
|
100 |
c) Portage integration |
101 |
|
102 |
A goal of the security project is to integrate glsa-check and other useful |
103 |
security related tools into portage. glsa-check had a lot of improvements |
104 |
recently but unfortunately the portage code is considered as not yet ready |
105 |
for a glsa-check integration. Until this changes, portage 2.1 is expected to |
106 |
bring up some new and interesting features in a security point of view, like |
107 |
security.mask or running glsa-check in a post_sync. |
108 |
|
109 |
|
110 |
d) Other process or policy improvements |
111 |
|
112 |
Nothing special to mention here. |
113 |
|
114 |
|
115 |
|
116 |
|
117 |
3/ Lead(s) election: |
118 |
-------------------- |
119 |
|
120 |
- Koon (Thierry Carrez) stepped back from operational lead |
121 |
- Plasmaroo (Tim Yamin) is old and new kernel subproject leader |
122 |
- Taviso (Tavis Ormandy) is old and new auditing subprojet leader |
123 |
- Jaervosz (Sune Kloppenborg Jeppesen) is old and new operational lead |
124 |
- DerCorny (Stefan Cornelius) is new operational lead |
125 |
|
126 |
|
127 |
|
128 |
4/ Public Q&A: |
129 |
-------------- |
130 |
|
131 |
Nothing special to mention here, too. The Gentoo Linux Security team is always |
132 |
open to new ideas or questions. Write an email to security@g.o or visit |
133 |
us on IRC, #gentoo-security in the freenode network. |
134 |
|
135 |
|
136 |
EOF |
137 |
|
138 |
-- |
139 |
gentoo-security@g.o mailing list |