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] [2] [3] [4] [5]