[gentoo-commits] gentoo commit in xml/htdocs/security/en: coordinator_guide.xml vulnerability-policy.xml

[gentoo-commits] gentoo commit in xml/htdocs/security/en: coordinator_guide.xml vulnerability-policy.xml

[Alex Legler (a3li)]

a3li        11/05/15 19:38:51

  Modified:             coordinator_guide.xml vulnerability-policy.xml
  Log:
  Updating Vulnerability Policy and Coordinator Guide

Revision  Changes    Path
1.26                 xml/htdocs/security/en/coordinator_guide.xml

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/en/coordinator_guide.xml?rev=1.26&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/en/coordinator_guide.xml?rev=1.26&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/en/coordinator_guide.xml?r1=1.25&r2=1.26

Index: coordinator_guide.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/en/coordinator_guide.xml,v
retrieving revision 1.25
retrieving revision 1.26
diff -u -r1.25 -r1.26
--- coordinator_guide.xml	30 Oct 2009 10:31:52 -0000	1.25
+++ coordinator_guide.xml	15 May 2011 19:38:51 -0000	1.26
@@ -14,6 +14,9 @@
 <author title="Author">
   <mail link="rbu@gentoo.org">Robert Buchholz</mail>
 </author>
+<author title="Author">
+  <mail link="a3li@gentoo.org">Alex Legler</mail>
+</author>
 
 <abstract>
 This document contains procedures, tips and tricks applying to the
@@ -24,8 +27,8 @@
 <!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
 <license/>
 
-<version>0.8.8</version>
-<date>2008-05-09</date>
+<version>0.9</version>
+<date>2011-05-15</date>
 
 <chapter>
 <title>Prerequisites</title>
@@ -165,8 +168,7 @@
 <p>
 Kernel vulnerabilities are treated using a separate procedure. To easily
 distinguish them from the other bugs, they are filed under the <c>Kernel</c>
-category. Kernel bugs do not result in GLSAs but have their own publication
-system (Gentoo KISS).
+category. Kernel bugs do not result in GLSAs.
 </p>
 
 </body>
@@ -207,7 +209,7 @@
 until a public release, usually known as the embargo date or coordinated release date.
 Restricted bugs have the "Gentoo Security" checkbox
 checked and therefore can only be accessed by Gentoo Security Team members.
-External people (package maintainer, arch testers, Release Engineering) may be
+External people (package maintainers, arch testers) may be
 added on a per-name basis, aliases should never be used (because they are too
 wide and won't allow bug comments).
 </p>
@@ -269,11 +271,6 @@
 <ti>The bug status, with optional extra information</ti>
 <ti>[ebuild+]</ti>
 </tr>
-<tr>
-<ti>coordinator</ti>
-<ti>The nickname of the coordinator assigned to the bug, optional</ti>
-<ti>koon</ti>
-</tr>
 </table>
 
 <p>
@@ -321,6 +318,14 @@
 <ti>glsa+</ti>
 <ti>The GLSA is late, any GLSA coordinator can correct and send it</ti>
 </tr>
+<tr>
+<ti>cleanup</ti>
+<ti>Waiting for the Gentoo package maintainer to remove vulnerable ebuilds from the tree</ti>
+</tr>
+<tr>
+<ti>cleanup+</ti>
+<ti>No response from the maintainer, the Security Team should remove vulnerable ebuilds as needed</ti>
+</tr>
 </table>
 
 <p>
@@ -344,11 +349,6 @@
 <ti>upstream+, ebuild+</ti>
 </tr>
 <tr>
-<ti>Arch names</ti>
-<ti>When only one or two supported arches are blocking the bug</ti>
-<ti>stable+</ti>
-</tr>
-<tr>
 <ti>tempglsa</ti>
 <ti>When a temporary GLSA was issued as a temporary solution</ti>
 <ti>upstream+, ebuild+</ti>
@@ -369,10 +369,7 @@
 <ti>C0 [stable]</ti>
 </tr>
 <tr>
-<ti>A3 [ebuild] jaervosz</ti>
-</tr>
-<tr>
-<ti>B1 [stable+ amd64] koon</ti>
+<ti>B1 [stable blocked]</ti>
 </tr>
 </table>
 
@@ -384,12 +381,14 @@
 
 <p>
 When the fix is not available from the upstream developer and/or there is
-no official patch to solve the problem, the bug is in [upstream] status. If
-the solution must be found amongst Gentoo developers, the bug is in [inhouse]
-status. If a fix is available, the bug is in [ebuild] status.
-If a fix ebuild is put
-in the portage tree, the bug is in [stable] status. When the fix ebuild is
-in portage with all required keywords set, the bug is in [glsa] status.
+no official patch to solve the problem, the bug is in <c>[upstream]</c> status.
+If a fix is available, the bug is in <c>[ebuild]</c> status.
+If a fixed ebuild is put in the Portage tree, the next step is stabilizing, so
+the bug is in <c>[stable]</c> status.
+When the fixed ebuild is in Portage with all required keywords set and if the
+issue is severe enough to warrant a GLSA, the bug is in <c>[glsa]</c> status.
+Is the bug not severe enough, GLSA voting is next, so the status would be
+<c>[glsa?]</c>.
 </p>
 
 </body>
@@ -399,18 +398,18 @@
 <body>
 
 <p>
-In [upstream] status, we wait for the fix version or a decent patch to
+In <c>[upstream]</c> status, we wait for the fixed version or a decent patch to
 appear. This status requires to regularly check upstream for information:
-development and announce mailing lists, websites, Bugs database, CVS when
-available, are all relevant sources of information. Unofficial patches must
-be taken into account only if the upstream developer does not react to the
+development and announce mailing lists, websites, bugs database, VCS when
+available, are all other relevant sources of information. Unofficial patches
+must be taken into account only if the upstream developer does not react to the
 vulnerability, and they must be thoroughly double-checked to ensure they
 are not evil. When a fix version is announced or a patch is found, the bug
-enters [ebuild] status.
+enters <c>[ebuild]</c> status.
 </p>
 
 <p>
-If there is no reaction from upstream and no patch, we enter [upstream+]
+If there is no reaction from upstream and no patch, we enter <c>[upstream+]</c>
 status. The only option here is to security-mask the vulnerable package
 and issue a temporary GLSA if needed. See the policy for more details on the
 security masking approval procedure. The status whiteboard should then be
@@ -425,23 +424,24 @@
 <body>
 
 <p>
-In [ebuild] status, we must identify the maintainer of the package, and
-summon him to commit a fix ebuild. Sources to identify the herd or developer
+In <c>[ebuild]</c> status, we must identify the maintainer of the package, and
+summon him to commit a fixed ebuild. Sources to identify the herd or developer
 responsible for maintaining a package are the metadata.xml file in the
 directory of the package in portage and the Changelog file showing who did the
-latest version bumps. You should Cc: the herd and/or maintainer responsible
-for the package on the bug and ask him to provide an ebuild for the fix
+latest version bumps. You should Cc: the herd and maintainer responsible
+for the package on the bug and ask him to provide an ebuild for the fixed
 version. You should periodically check that an ebuild wasn't committed
-to portage without any comment on the bug (it happens). When the ebuild
-appears, the bug enters [stable] status.
+to Portage without any comment on the bug (it happens). When the ebuild
+appears, the bug enters <c>[stable]</c> status.
 </p>
 
 <p>
-If the maintainer doesn't show up, we enter [ebuild+] status. In case a fixed
-version is available, you should test if a simple version bump (renaming the 
-ebuild to the version and emerging it) works. If only a patch is available, you
-should test if it applies cleanly. Then you should find a security bug wrangler
-with x86 commit rights to do the bump and mark the ebuild ~ for testing.
+If the maintainer doesn't show up, we enter <c>[ebuild+]</c> status. In case a
+fixed version is available, you should test if a simple version bump (renaming
+the ebuild to the needed/fixed version and emerging it) works.
+If only a patch is available, you should test if it applies cleanly.
+Then you should find a Security Team member with Portage tree commit rights to
+do the bump and mark the ebuild <c>~</c> for testing.
 </p>
 
 <p>
@@ -449,7 +449,7 @@
 the only option is to security-mask the unmaintained package and issue a
 temporary GLSA if needed. See the policy for more details on the
 security masking approval procedure. The status whiteboard should then be
-flagged with masked and/or tempglsa keywords and bug severity set to
+flagged with <c>masked</c> and/or <c>tempglsa</c> keywords and bug severity set to
 <c>enhancement</c>.
 </p>
 
@@ -460,11 +460,11 @@
 <body>
 
 <p>
-In [stable] status, you have to determine what KEYWORDS the provided ebuild
-needs before the GLSA can go out. This can be tricky. You have to consider
-every version currently in portage so that the fix ebuild has <e>equally or
-more stable</e> keywords than any other packages in portage. Here is an
-example:
+In <c>[stable]</c> status, you have to determine what KEYWORDS the provided 
+ebuild needs before the GLSA can go out. This can be tricky.
+You have to consider every version currently in portage so that the fix
+ebuild has <e>equally or more stable</e> keywords than any other packages
+in Portage. Here is an example:
 </p>
 
 <table>
@@ -493,34 +493,29 @@
 <note>
 You can use <uri>http://packages.gentoo.org</uri> to help you determine
 the needed KEYWORDS. If affected packages were removed by the package
-maintainer too early, you should use the
-<uri link="http://www.gentoo.org/cgi-bin/viewcvs.cgi/">CVS access</uri>
+maintainer too early, you should use our
+<uri link="http://sources.gentoo.org/cgi-bin/viewvc.cgi">ViewVC</uri>
 to dig in the Attic and look for old KEYWORDS.
 </note>
 
 <p>
-Once determined (and noted for reference on the bug) the needed KEYWORDS,
-you should Cc: arch teams and ask them to mark the ebuild stable or ~
+Once you have determined (and noted for reference on the bug) the needed KEYWORDS,
+you should Cc: arch teams and ask them to mark the ebuild stable or testing
 accordingly. To make sure that the arch teams will pick the bug up, don't forget
 to add "STABLEREQ" to the bug's "Keywords" field. The arches alias are
 archname@gentoo.org (x86@gentoo.org, ppc@gentoo.org...). All arches (including
 "unsupported" arches) must be called. But note that only "supported" arches (as
-defined in the policy) are needed before the bug can advance to [glsa] status
+defined in the policy) are needed before the bug can advance to <c>[glsa]</c> status
 You should periodically check for new keywords in the ebuild, as sometimes they
 are changed without a comment in the bug. As soon as the required KEYWORDS
-are in the ebuild for all supported arches, the bug enters [glsa] status.
-</p>
-
-<p>
-During a release preparation period you should also Cc: Release Engineering
-(release@gentoo.org) on all bugs with [stable] status.
+are in the ebuild for all supported arches, the bug enters <c>[glsa]</c> status.
 </p>
 
 <p>
 If the arch teams take too much time testing and changing the KEYWORDS, or
 they refuse to mark stable a package due to outstanding problems, the bug
-enters [stable+] status. We must track down arch-maintainers to have them
-mark stable, help testing. You should also convince the arches that if they
+enters <c>[stable+]</c> status. We must track down arch maintainers to have them
+mark stable or help testing. You should also convince the arches that if they
 discover a bug in the ebuild that already was in previous "stable" versions,
 the ebuild should be marked "stable" anyway, even if it's not really stable,
 as specified in the policy. If the KEYWORDS can't be met, the only other
@@ -535,23 +530,51 @@
 <body>
 
 <p>
-In [glsa] status, the security bug is corrected. We need to issue the GLSA
+In <c>[glsa]</c> status, the security bug is corrected. We need to issue the GLSA
 or close the bug without GLSA. The policy determines the cases where a GLSA
 is needed and where a GLSA is not needed. There are also cases where a GLSA
-vote must take place to decide if a GLSA is needed ([glsa?] status).
+vote must take place to decide if a GLSA is needed (<c>[glsa?]</c> status).
 If at least two Security Team members vote for "no GLSA", then no GLSA should
-be issued. The bug remains in [glsa] status until a GLSA is published.
+be issued. The bug remains in <c>[glsa]</c> status until a GLSA is published.
 </p>
 
 <p>
-When a GLSA is needed but nothing was sent, the bug enters [glsa+] status.
-It's the case when the assigned GLSA coordinator did not draft and/or
-made peer-reviewed and/or sent his GLSA. Other members of the Security Team
-should take the lead at this point and finalize the GLSA.
+When a GLSA is needed but nothing was sent, the bug enters <c>[glsa+]</c> status.
+This is the case when there are delays during drafting, reviewing or sending
+the advisory. Any member of the Security Team should take the lead and finalize
+the GLSA.
 </p>
 
 </body>
 </section>
+<section>
+<title>Bugs in [cleanup] status</title>
+<body>
+
+<p>
+This status is not in order like the others. It is used to denote that the
+maintainer needs to remove vulnerable ebuild versions in the tree.
+</p>
+
+<p>
+For example, the <e>foo</e> package has a vulnerability in versions earlier
+than 1.23. The version 1.24 was added to Portage and is stable already
+(i.e. the stabilization was done before the security impact of the release was
+known), only old ebuilds need to be removed. The next status in this case would
+be <c>[glsa]</c> or <c>[glsa?]</c> depending on severity.
+</p>
+
+<p>
+Another use case might be when a package was updated, and all steps are done
+(i.e. a GLSA was sent or the team decided against sending one), but the
+vulnerable ebuilds should really be removed to avoid users accidentally
+installing them, the bug could be left open and set to the <c>[cleanup]</c>
+state. This is usually not needed tough, but may be used on a case-to-case base
+when the Security Team has an elevated interest in vulnerable ebuilds
+getting removed for whatever reasons.
+</p>
+</body>
+</section>
 </chapter>
 <chapter>
 <title>Confidential vulnerability bug management</title>
@@ -560,8 +583,8 @@
 <body>
 
 <p>
-Confidential bugs should be following this pattern: "RATING [status]
-coordinator KEYWORD CRD", where:
+Confidential bugs should be following this pattern: <c>RATING [status]
+KEYWORD CRD</c>, where:
 </p>
 
 <table>
@@ -581,11 +604,6 @@
 <ti>[ebuild+]</ti>
 </tr>
 <tr>
-<ti>coordinator</ti>
-<ti>The nickname of the coordinator assigned to the bug, optional</ti>
-<ti>koon</ti>
-</tr>
-<tr>
 <ti>KEYWORD</ti>
 <ti>The confidentiality level of the bug, can be CLASSIFIED, CONFIDENTIAL, SEMI-PUBLIC</ti>
 <ti>CLASSIFIED</ti>
@@ -631,13 +649,13 @@
 
 <p>
 Confidential and classified bugs need extra care. The ebuild and files fixing
-the vulnerability should NOT be committed to portage CVS, and no part of those
-bugs should ever be discussed in public. Patches or portage overlay tarballs
-can be attached to the bug, though. Testers will have to setup their own
-overlay to test it.
+the vulnerability should NOT be committed to the Portage tree, and no part of
+those bugs should ever be discussed in public. Patches or Portage overlay
+tarballs can be attached to the bug, though.
+Testers will have to setup their own overlay to test it.
 The idea with those bugs is to prepare the ebuild and have it tested for the
 coordinated release date, so that it can be released with all needed KEYWORDS
-together with the GLSA at the same time the issue goes public.
+together with the GLSA at the same time or shortly after the issue goes public.
 </p>
 
 </body>
@@ -1201,3 +1219,4 @@
 </section>
 </chapter>
 </guide>
+<!-- vim: set et noai inde=: -->



1.22                 xml/htdocs/security/en/vulnerability-policy.xml

file : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/en/vulnerability-policy.xml?rev=1.22&view=markup
plain: http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/en/vulnerability-policy.xml?rev=1.22&content-type=text/plain
diff : http://sources.gentoo.org/viewvc.cgi/gentoo/xml/htdocs/security/en/vulnerability-policy.xml?r1=1.21&r2=1.22

Index: vulnerability-policy.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/security/en/vulnerability-policy.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- vulnerability-policy.xml	14 Apr 2009 00:06:25 -0000	1.21
+++ vulnerability-policy.xml	15 May 2011 19:38:51 -0000	1.22
@@ -14,6 +14,9 @@
 <author title="Author">
   <mail link="rbu@gentoo.org">Robert Buchholz</mail>
 </author>
+<author title="Author">
+  <mail link="a3li@gentoo.org">Alex Legler</mail>
+</author>
 
 <abstract>
 This document describes the policy used in Gentoo Linux to treat
@@ -25,8 +28,8 @@
 <!-- See http://creativecommons.org/licenses/by-sa/1.0 -->
 <license/>
 
-<version>1.2.7</version>
-<date>2009-04-14</date>
+<version>1.3</version>
+<date>2011-05-15</date>
 
 <chapter>
 <title>Scope</title>
@@ -45,7 +48,7 @@
 </p>
 
 <p>
-For this reason, the security team separates Gentoo architectures into two
+For this reason, the Security Team separates Gentoo architectures into two
 groups, <b>supported</b> and <b>unsupported</b>:
 </p>
 
@@ -106,34 +109,19 @@
 </body>
 </section>
 <section>
-<title>Release Engineering</title>
-<body>
-<p>
-The Release Engineering ("releng") project appoints a developer to be the
-primary point of contact for security issues.
-</p>
-<p>
-Release Engineering informs the Gentoo Security Project when a first tree 
-snapshot is taken for media releases. Beginning with the first snapshot until 
-the official media release ("release preparation period"), Release Engineering 
-(the appointed security liaison in case of confidential issues) should be cc'd 
-on each security bug entering the stabilization phase.
-</p>
-</body>
-</section>
-<section>
 <title>Kernels</title>
 <body>
 
 <p>
-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 
-<e>no GLSA will be issued</e> when everything is solved.
+<b>no GLSA will be issued</b> when everything is solved.
 </p>
 
 <note>
-This policy should be changed when new tools are added to cover
-security vulnerabilities affecting the different kernel sources.
+The <uri link="http://git.overlays.gentoo.org/gitweb/?p=proj/kernel-check.git;a=summary">kernel-check</uri>
+utility is being developed to provide Kernel security information.
+This policy should be updated accordingly when it is ready.
 </note>
 
 </body>
@@ -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 
-<e>no GLSA will be issued</e> when everything is solved.
+<b>no GLSA will be issued</b> when everything is solved.
 </p>
 
 <note>
 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.
 </note>
 
 </body>
@@ -174,7 +162,7 @@
 <mail link="security@gentoo.org">security@gentoo.org</mail>).
 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.
 </p>
 
 </body>
@@ -185,24 +173,24 @@
 
 <p>
 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.
 </p>
 
 <note>
 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 
 <uri link="http://security.gentoo.org">security.gentoo.org</uri>, their key
 IDs can be looked up on the
 <uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">Gentoo
 Linux Developers List</uri>
 and their keys can be retrieved from the
 <uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri> keyserver.
+The use of IRC and other unencrypted messaging methods is discouraged.
 </note>
 
 </body>
@@ -312,7 +300,7 @@
 
 <p>
 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:
 </p>
 
 <table>
@@ -389,22 +377,27 @@
 
 <p>
 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:
 </p>
 
 <ul>
 <li>rename the bug so that it includes category/package-name at start
-    (for example: "net-mail/clamav: DoS using RAR files")</li>
+    (for example: <e>net-mail/clamav: DoS using RAR files</e>)</li>
+<li>remove version information in the bug title if there is no fixed version
+    available. Bug titles like <e>&lt;=category/package-1.2.3</e>, where 1.2.3
+    is the latest version of the package, should be avoided.</li>
 <li>evaluate and assign a severity level (see above)</li>
-<li>set the status to ASSIGNED</li>
+<li>set the status to IN_PROGRESS</li>
 <li>seed the status whiteboard to the correct severity code and status</li>
 <li>cc package maintainers to the bug according to package metadata</li>
 <li>set the URL field to an upstream bug or similar</li>
-<li>search for reserved or assigned CVE identifier and add it to the bug title, request a CVE otherwise</li>
-<li>optionally assign a GLSA coordinator for the bug, by adding the
-    coordinator name to the status whiteboard</li>
+<li>search for a reserved or assigned CVE identifier and add it to the bug title,
+    request a CVE otherwise</li>
+<li>enter the bug number in the CVE tracker (given the wrangler has access to it)</li>
+<li>set the Alias field to the CVE identifier.
+    In case there are multiple identifiers, use the first one.</li>
 </ul>
 
 <warn>
@@ -451,8 +444,8 @@
 <li>if a fix is available, get the package maintainer involved to produce and
     commit an ebuild containing the fix and set status whiteboard to <c>ebuild</c></li>
 <li>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 <c>stable</c></li>
 <li>arch-maintainers should mark the ebuild stable if there is no regression
@@ -464,7 +457,7 @@
 
 <note>
 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.
 </note>
 
@@ -486,19 +479,19 @@
     <c>stable+</c> and <c>glsa+</c></li>
 <li>if no upstream fix is available (<c>upstream+</c> 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</li>
 <li>if the maintainer/herd does not show up for producing the ebuild during 48
-    hours after summoning (<c>ebuild+</c> status), the security team should
+    hours after summoning (<c>ebuild+</c> status), the Security Team should
     try to bump the ebuild by itself</li>
 <li>if testing and marking stable takes too much time (<c>stable+</c> 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)</li>
 <li>if the GLSA coordinator does not show up to draft a GLSA (<c>glsa+</c>
-    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</li>
 </ul>
 
@@ -534,6 +527,10 @@
 <title>Temporary GLSAs</title>
 <body>
 
+<note>
+This is no longer common practice.
+</note>
+
 <p>
 If a <e>blocker</e> or <e>critical</e> or <e>major</e> vulnerability cannot
 totally be corrected in the target delay,
@@ -562,7 +559,7 @@
 
 <p>
 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.
 </p>
 
@@ -645,7 +642,7 @@
 <note>
 Developer key IDs can be found on the Gentoo Linux
 <uri link="http://www.gentoo.org/proj/en/devrel/roll-call/userinfo.xml">
-Developer list</uri>. All the security team GPG keys are published on public
+Developer list</uri>. All the Security Team GPG keys are published on public
 key servers, including (but not limited to)
 <uri link="http://subkeys.pgp.net:11371">subkeys.pgp.net</uri>.
 </note>
@@ -712,3 +709,4 @@
 </section>
 </chapter>
 </guide>
+<!-- vim: set et noai inde=: -->