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