From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1KL0vl-0001SV-QK for garchives@archives.gentoo.org; Mon, 21 Jul 2008 19:20:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 02B15E0192; Mon, 21 Jul 2008 19:20:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 93631E040D; Mon, 21 Jul 2008 18:49:30 +0000 (UTC) Received: from [134.76.2.39] (vpn-2039.gwdg.de [134.76.2.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id EB2136751F; Mon, 21 Jul 2008 18:49:28 +0000 (UTC) Message-ID: <4884DA2C.1000306@gentoo.org> Date: Mon, 21 Jul 2008 20:49:16 +0200 From: Matthias Geerdsen User-Agent: Thunderbird 2.0.0.14 (X11/20080620) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo development announcement list X-BeenThere: gentoo-dev-announce@lists.gentoo.org MIME-Version: 1.0 To: gentoo-security@gentoo.org, gentoo-dev-announce@gentoo.org CC: Gentoo Security Team Subject: [gentoo-dev-announce] Security project meeting summary References: <48793BC5.1020604@gentoo.org> In-Reply-To: <48793BC5.1020604@gentoo.org> X-Enigmail-Version: 0.95.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig10EEF737F5314CD84CF40FAF" X-Archives-Salt: 1e69a17d-3f35-4a5c-b803-99434fd43b41 X-Archives-Hash: 4c21613342947131d8d174ed06041a77 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig10EEF737F5314CD84CF40FAF Content-Type: multipart/mixed; boundary="------------060507060609070904030504" This is a multi-part message in MIME format. --------------060507060609070904030504 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: quoted-printable Hi, I attached a summary of last week's meeting. The summary and the log are = also=20 linked from [1] and should find their way to our /proj dir in the end. Matthias [1] --=20 Matthias Geerdsen vorlon@gentoo.org Gentoo Linux Security Team http://security.gentoo.org --------------060507060609070904030504 Content-Type: text/plain; name="meeting-summary-20080714.txt" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline; filename="meeting-summary-20080714.txt" Gentoo Security Project Meeting 2008-07-14 ****************************************** Agenda ------ 1) Project status 2) Recruitment 3) Delays in bug resolution/GLSA publication=20 4) GLSA related issues 4.1) New date format in GLSAs 4.2) Slot support 5) Handling of CVE identifiers in bugs=20 6) Possible changes to the Vulnerability Policy 6.1) Insecure creation of temporary files 6.2) SQL Injection 7) Security support for games 8) Any other topic Summary ------- ad 1) Project status - The auditing as well as the kernel security subproject are dead at th= e moment. The kernel project should be revived when possible and auditi= ng 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 le= ft 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 produc= t, a mentor should look after the edits of his assigned padawan. The privi= lege should be given after about of 1 to 2 weeks of active work as a scout= =2E Infra will have to be contacted about the possibilities to give out editbugs privilege.=20 - rbu and mjf will work on new documentation for padawans. - vorlon will prepare a blog post or an article to invite more people t= o 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 gi= ven 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 lea= ving before they even gain access to GLSAMaker. To make earlier contributi= on 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 revisi= on 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 GL= SA files in GLSAMaker and CVS are available. - A patch for glsa-check has been attached in bugzilla. Possible impa= cts 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 require= s 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 th= en should be brought up with neysx/docs team to prepare a new DTD vers= ion. Then then the implementation should be discussed with the portage t= eam. - 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 entere= d 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 be= tween bugs, GLSAs and CVE ids, which needs to be searchable. - As it is currently not easily possible to find the bug to a certain C= VE 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, b= ut 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] a= nd don't get fixed, a discussion was raised on how to handle vulnerabilities i= n games in general. - Since it was neither wanted to declare games as unsupported by the se= curity 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 mi= ght need a change in the policies. - vorlon will look into needed additions or changes to the vulnerabilit= y 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 w= ith 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 wou= ld also make the work more transparent and could get more people involve= d. - 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] --------------060507060609070904030504-- --------------enig10EEF737F5314CD84CF40FAF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiE2jEACgkQGc/RGrFqUYMyFACfTm4PORQf8GjNBYRVOY3WbFLm 0b0An36CdISZh1p9byvZzqQa9fWg3jL0 =Mki5 -----END PGP SIGNATURE----- --------------enig10EEF737F5314CD84CF40FAF--