Scope

-For this reason, the security team separates Gentoo architectures into two +For this reason, the Security Team separates Gentoo architectures into two groups, supported and unsupported:

Kernels

-Currently kernels are not covered by the GLSA release process. +Kernels are not covered by the GLSA release process. Vulnerabilities must still be reported and will be fixed, but -no GLSA will be issued when everything is solved. +no GLSA will be issued when everything is solved.

-This policy should be changed when new tools are added to cover -security vulnerabilities affecting the different kernel sources. +The kernel-check +utility is being developed to provide Kernel security information. +This policy should be updated accordingly when it is ready. @@ -148,13 +136,13 @@ newer (~ARCH) ebuild, but the older (stable) packages are not affected, or when the package has never had any stable ebuilds in the tree. In this case the vulnerability must still be reported and will be fixed, but -no GLSA will be issued when everything is solved. +no GLSA will be issued when everything is solved.

This policy might be changed when our tools support more complex upgrade paths and if a sufficient number of GLSA coordinators join -the security team. +the Security Team. @@ -174,7 +162,7 @@ security@gentoo.org). Major security lists should have official scouts assigned to them which should ensure that all vulnerabilities announced on these lists get a -security bugzilla entry. +security Bugzilla entry.

@@ -185,24 +173,24 @@

Confidential vulnerabilities (for example coming from developer's direct -communication or restricted vendor-sec lists) should follow a specific -procedure. They should not appear as a public -bugzilla entry, but only in security-restricted media like a private -bugzilla section or the GLSAMaker tool. They should get -corrected using private communication channels between the GLSA coordinator -and the package maintainer. +communication or restricted lists) must follow a specific procedure. +They should not appear as a public bugzilla entry, but only in +security-restricted media like a private bugzilla section or the GLSAMaker tool. +They should get corrected using private communication channels between the GLSA +coordinator and the package maintainer.

Communication for confidential vulnerabilities should be properly encrypted. -They should be sent to specific security team members and encrypted with -their GPG key. The list of the security team members is available at +They should be sent to specific Security Team members and encrypted with +their GPG key. The list of the Security Team members is available at security.gentoo.org, their key IDs can be looked up on the Gentoo Linux Developers List and their keys can be retrieved from the subkeys.pgp.net keyserver. +The use of IRC and other unencrypted messaging methods is discouraged. @@ -312,7 +300,7 @@

Here is the table of the resulting severity levels. They should be set -to the bugzilla severity level of the same name: +to the Bugzilla severity level of the same name:

@@ -389,22 +377,27 @@

During this phase it may be necessary to ask the reporter for details. The bug -remains with status NEW as long as necessary. When (if) the bug passes these -sanity tests, it should be accepted and the bug wrangler should do the -following: +remains with status UNCONFIRMED or CONFIRMED as long as necessary. +When (if) the bug passes these sanity tests, it should be marked as IN_PROGRESS +and the bug wrangler should do the following:

rename the bug so that it includes category/package-name at start - (for example: "net-mail/clamav: DoS using RAR files")

net-mail/clamav: DoS using RAR files

remove version information in the bug title if there is no fixed version + available. Bug titles like <=category/package-1.2.3, where 1.2.3 + is the latest version of the package, should be avoided.
evaluate and assign a severity level (see above)
set the status to ASSIGNED
set the status to IN_PROGRESS
seed the status whiteboard to the correct severity code and status
cc package maintainers to the bug according to package metadata
set the URL field to an upstream bug or similar
search for reserved or assigned CVE identifier and add it to the bug title, request a CVE otherwise
optionally assign a GLSA coordinator for the bug, by adding the - coordinator name to the status whiteboard
search for a reserved or assigned CVE identifier and add it to the bug title, + request a CVE otherwise
enter the bug number in the CVE tracker (given the wrangler has access to it)
set the Alias field to the CVE identifier. + In case there are multiple identifiers, use the first one.

@@ -451,8 +444,8 @@

if a fix is available, get the package maintainer involved to produce and commit an ebuild containing the fix and set status whiteboard to ebuild

once an ebuild is committed, evaluate what keywords are needed for the fix - ebuild and get arch-specific teams to test and mark - the ebuild stable on their architectures (arch-teams should be cc'd on + ebuild and get arch-specific Teams to test and mark + the ebuild stable on their architectures (arch teams should be cc'd on the bug, as well as releng during release preparation) and set status whiteboard to stable

arch-maintainers should mark the ebuild stable if there is no regression @@ -464,7 +457,7 @@ If the bug makes progress and the assigned GLSA coordinator does not react, -the other members of the security team can help keeping the bug rolling by +the other members of the Security Team can help keeping the bug rolling by updating its status. @@ -486,19 +479,19 @@ stable+ and glsa+

if no upstream fix is available (upstream+ status), a decision must be taken on masking the - package: the security team can mask a package which is not depended on by - itself, but need a TLP manager approval before masking a package which is + package: The Security Team can mask a package which is not depended on by + itself, maintainers should be consulted before masking a package which is not standalone

if the maintainer/herd does not show up for producing the ebuild during 48 - hours after summoning (ebuild+ status), the security team should + hours after summoning (ebuild+ status), the Security Team should try to bump the ebuild by itself

if testing and marking stable takes too much time (stable+ status), - the security team will shout on IRC channels and gentoo-dev list to get + the Security Team will shout on IRC channels and gentoo-dev list to get more testers. It will either mark the ebuild stable by itself or, in the event this cannot be done due to stability issues, mask it (see security masking approval policy above)

if the GLSA coordinator does not show up to draft a GLSA (glsa+ - status), then another member of the security team should draft the GLSA + status), then another member of the Security Team should draft the GLSA and submit it to peer review

@@ -534,6 +527,10 @@ Temporary GLSAs + +This is no longer common practice. + +

If a blocker or critical or major vulnerability cannot totally be corrected in the target delay, @@ -562,7 +559,7 @@

Once ready, a GLSA should be submitted to peer review. At least two members -of the security team must approve the draft GLSA. Once the draft passes the +of the Security Team must approve the draft GLSA. Once the draft passes the peer review process, it should be assigned an official GLSA number.

@@ -600,28 +597,6 @@ - Bugtraq security mailing-list - - bugtraq@securityfocus.com - - - - Full-disclosure security mailing-list - - - full-disclosure@lists.grok.org.uk - - - - - Linuxsecurity.com advisories service - - - security-alerts@linuxsecurity.com - - - -Gentoo Linux announcement forumhttp://forums.gentoo.org/viewforum.php?f=16 @@ -633,7 +608,6 @@

The To: field must be set to gentoo-announce
The Cc: filed must contain the other email addresses
The From: and Return-Path: must be set to the GLSA coordinator @gentoo.org address
The Subject: field must be "[ GLSA XXXXYY-ZZ ] Your vulnerability @@ -645,7 +619,7 @@ Developer key IDs can be found on the Gentoo Linux -Developer list. All the security team GPG keys are published on public +Developer list. All the Security Team GPG keys are published on public key servers, including (but not limited to) subkeys.pgp.net. @@ -655,10 +629,19 @@ handled by an automatic poster when it receives the announcement. + +Starting Feb 2, 2012, we have decied to no longer CC any third parties. +The gentoo-announce mailing list has little other traffic, so that they +should be subscribed there. General security mailing lists such as full- +disclosure or bugtraq are not our target audience, and having various +distributions send notices about the same issues is not of any use to most +readers there, they too should be on gentoo-announce. + +
When the GLSA has been published the corresponding bugzilla bug should be resolved as FIXED, with the GLSA number referenced in the comments section -of the bug. +of the bug. GLSAMaker 2 offers this option after releasing the advisory.
@@ -712,3 +695,4 @@ +