diff options
Diffstat (limited to 'meetings/logs/20080714-summary.txt')
| -rw-r--r-- | meetings/logs/20080714-summary.txt | 156 |
1 files changed, 156 insertions, 0 deletions
diff --git a/meetings/logs/20080714-summary.txt b/meetings/logs/20080714-summary.txt new file mode 100644 index 0000000..caaf726 --- /dev/null +++ b/meetings/logs/20080714-summary.txt @@ -0,0 +1,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> |