1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
|
Gentoo Security Project Meeting 2008-07-14
******************************************
Agenda
------
1) Project status
* Short overview of the current status of the Gentoo Security Project
2) Recruitment
* What can be done to improve the current situation?
3) Delays in bug resolution/GLSA publication
* Where are the delays located and what can be done about them?
4) GLSA related issues
4.1) New date format in GLSAs
4.2) Slot support
5) Handling of CVE identifiers in bugs
* Define a way/ways to specify CVE ids in bugs (title/alias/...).
* Documentation is needed on how to search for CVE ids.
* CVE Compatibility
6) Possible changes to the Vulnerability Policy
6.1) Insecure creation of temporary files
6.2) SQL Injection
7) Security support for games
* Should games be fully security-supported or be handled in a different
way than other packages?
8) Any other topic
Summary
-------
ad 1) Project status
- The auditing as well as the kernel security subproject are dead at the
moment. The kernel project should be revived when possible and auditing
could be revived when somebody steps up who is interested in it. Dead
projects should be removed from the project page and/or marked as
inactive. (Discussion of kernel security was postponed at this point.)
- The project is currently suffering a lack of new recruits/... .
ad 2) Recruitment
- After the cleaning of the list of padawans [1] only one person was left
there and one was willing to come back. Many recruits became inactive only
a short while after they joined.
- It was proposed to give scouts the editbugs priv on bugzilla, so they can
also edit bugs which have not been filed by themselves. Since it is
currently not possible to restrict that privilege to a certain product, a
mentor should look after the edits of his assigned padawan. The privilege
should be given after about of 1 to 2 weeks of active work as a scout.
Infra will have to be contacted about the possibilities to give out
editbugs privilege.
- rbu and mjf will work on new documentation for padawans.
- vorlon will prepare a blog post or an article to invite more people to
help out in the project.
ad 3) Delays in bug resolution/GLSA publication
- The statistics [2], although possibly not a 100% accurate, show that
currently not even 50% of bugs are closed within the target delays given
by the vulnerability policy [3]. The main delay currently appears to be in
the drafting and reviewing of GLSAs.
- More recruits would help in this area, but the access to the drafting tool
(GLSAMaker) can currently not be given out too early, since it also
contains drafts for embargoed issues. This leads to many recruits leaving
before they even gain access to GLSAMaker. To make earlier contribution of
drafts easier, a new tool is needed. After some discussion about such new
tools, the topic was postponed as no short-term solution is available at
the moment.
ad 4) GLSA related issues
4.1) New date format in GLSAs
- The date format currently used in GLSAs is incorrect and the revision
number should not be included in the date, but in an attribute.
- A patch for GLSAMaker as well as a script to convert all current GLSA
files in GLSAMaker and CVS are available.
- A patch for glsa-check has been attached in bugzilla. Possible impacts
of the change to portage need to be determined.
- The change should be announced before it goes live.
4.2) Slot support
- As a first step towards slot support in GLSAs, portage team requires a
versioning of the DTD/GLSAs.
- The discussion of details of slot support was postponed. A decision is
needed on how to change the DTD to allow for slot support, which then
should be brought up with neysx/docs team to prepare a new DTD version.
Then then the implementation should be discussed with the portage team.
- It was decided that all changes to the DTD should require versioning and
that such versioning should not be included as a new attribute in the XML
but as a new name for the DTD (glsa.dtd, glsa-2.dtd, ...).
- The change of the date format and the introduction of slot support in the
DTD should occur at the same time.
ad 5) Handling of CVE identifiers in bugs
- Currently the CVE id of an issue is added to the summary of a bug and
as an alias for the bug. Multiple CVE ids for a single bug are entered in
the summary as e.g. (CVE-2008-{1234,1235,1236,1237}) which makes it
possible to use "CVE-2008 1234" as a search term to find the relevant bug.
Multiple ids in the alias field are not possible and a single bug per CVE
did not appear to be feasible. The method of putting CVE ids in bugs
should be added to the documentation.
- To achieve CVE compatibility at one point, a link needs to be made between
bugs, GLSAs and CVE ids, which needs to be searchable.
- As it is currently not easily possible to find the bug to a certain CVE
id, hoffie will work on a web based tool to allow such a search based on
the data available in SVN [4].
ad 6) Possible changes to the Vulnerability Policy
6.1) Insecure creation of temporary files
6.2) SQL Injection
- After a discussion of possible impacts and severity levels for those
vulnerabilities, it was decided not to add a fixed level for these, but to
add a note to the vulnerability policy to explain the possible levels and
the need to determine them case by case. rbu will work on such a note if
nobody else steps up to do so.
ad 7) Security support for games
- As currently many games are package masked for security reasons [5] and don't
get fixed, a discussion was raised on how to handle vulnerabilities in
games in general.
- Since it was neither wanted to declare games as unsupported by the security
team nor to keep them all marked as ~arch, it would be best to treat games
as other packages, but not to push for removal after masking. This might
need a change in the policies.
- vorlon will look into needed additions or changes to the vulnerability
policy and/or the GLSA coordinators guide.
ad 8) Any other topic
- It is wanted that vulnerable versions of packages be removed from the
tree when fixed versions are available and stable. Devs should be
informed about this by comments left in the bugs. Also py will try to come
up with a script to identify such packages in the tree.
- In general the dev manual and quizzes should be reviewed for security
related topics.
- It would be desirable to have a keyword for security related commits in
the Changelog files. The technical side of this should be discussed with
the portage team.
- Lead elections will be held at a later time, since several devs are
currently unavailable.
- Shorter meetings should be held more frequently and mail, especially the
gentoo-security@g.o mailing list, should be used more often. This would
also make the work more transparent and could get more people involved.
- It was noted again that nobody should open bugs marked as "CLASSIFIED" to
the public, as they might contain private emails for example and only bugs
marked "CONFIDENTIAL" should be opened after the agreed upon time.
[1] <http://www.gentoo.org/security/en/padawans.xml>
[2] <http://dev.gentoo.org/~vorlon/security/stats.xml>
[3] <http://www.gentoo.org/security/en/vulnerability-policy.xml>
[4] <https://overlays.gentoo.org/proj/security/browser/data/CVE/list>
[5] <http://tinyurl.com/66qaq8>
|
GitWeb