[gentoo-dev-announce] Security project meeting - Monday, 2008-07-14, 19:00 UTC

[gentoo-dev-announce] Security project meeting - Monday, 2008-07-14, 19:00 UTC

[Matthias Geerdsen]

[-- Attachment #1: Type: text/plain, Size: 835 bytes --]

Hi everyone,

the security project will hold a public meeting in #gentoo-security this monday, 
2008-07-14 at 19:00 UTC (21:00 CEST).
The tentative agenda looks as follows:


1) Project status

2) Recruitment

3) Delays in bug resolution/GLSA publication

4) GLSA related issues
   4.1) new date format
   4.2) slot support

5) Handling of CVE identifiers in bugs

6) Possible changes to the Vulnerability Policy
   6.1) Rating for "insecure creation of temporary files"
   6.2) Rating for "SQL injection"

7) Security support for games

8) Any other topic


Any changes to the agenda as well as related info can be found at [1].

[1] <http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml>


-- 
Matthias Geerdsen
vorlon@gentoo.org

Gentoo Linux Security Team
http://security.gentoo.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

[gentoo-dev-announce] Security project meeting summary

[Matthias Geerdsen]

[-- Attachment #1.1: Type: text/plain, Size: 345 bytes --]

Hi,

I attached a summary of last week's meeting. The summary and the log are also 
linked from [1] and should find their way to our /proj dir in the end.

Matthias


[1] <http://dev.gentoo.org/~vorlon/security/meeting-20080714.xml>

-- 
Matthias Geerdsen
vorlon@gentoo.org

Gentoo Linux Security Team
http://security.gentoo.org

[-- Attachment #1.2: meeting-summary-20080714.txt --]
[-- Type: text/plain, Size: 7376 bytes --]

Gentoo Security Project Meeting 2008-07-14
******************************************

Agenda
------

1) Project status
2) Recruitment
3) Delays in bug resolution/GLSA publication 
4) GLSA related issues
  4.1) New date format in GLSAs
  4.2) Slot support
5) Handling of CVE identifiers in bugs 
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 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>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]