Project:Security/GLSA Coordinator Guide
This document contains procedures, tips and tricks for the GLSA Coordinator job.
Prerequisites
Accounts
A certain number of accounts must be established before working as a GLSA coordinator. To draft GLSAs you must get a GLSAMaker account. To manage security bugs you need to have a Bugzilla account, which will be upgraded to editbugs privileges. To send GLSA announcements you need to have a yourname@gentoo.org address (i.e. to be a Gentoo developer). This address should be allowed to send to gentoo-announce. An account on git.gentoo.org allows you to commit the XML advisories. Finally you need an IRC name. You will be required to hang out in the #gentoo-security channel whenever you're available online.
All the names used should be consistent in order to allow easy identification.
GPG key
You must create a GPG key for your yourname@gentoo.org email address. You can either create a specific key or add the gentoo.org address to an existing key. The key ID should be set in the LDAP , and you should check that your name and key ID appears on the developer list . It is very important that the key is published at least on the subkeys.pgp.net keyserver. It can also be submitted on other keyservers.
Environment
Check out the git repository containing our advisories. Be sure to have set your name and email address in git properly set.
user $git clone git+ssh://git@git.gentoo.org/data/glsa.gitMailing-list subscriptions
As a security developer, you will be added to the gentoo-core list and security@gentoo.org alias. You should also subscribe to gentoo-announce, gentoo-dev and gentoo-security.
Security bug types and Bugzilla components
All security bugs are located in the Gentoo Security Bugzilla product. If you find a security bug which does not have the correct product name, please fix it immediately. There are several different types of security bugs, and each has its own component.
Vulnerability
Vulnerabilities are security bugs in the upstream software or introduced in the Gentoo ebuild packaging. These bugs result in GLSAs. Kernel bugs have their own category and should not filed as Vulnerability .
Kernel
Kernel vulnerabilities are treated using a separate procedure. To easily distinguish them from the other bugs, they are filed under the Kernel category. Kernel bugs do not result in GLSAs.
Default config
Gentoo packages should be as secure by default as possible. Default configuration bugs are filed when the default configuration shipped with the package can be improved in terms of security. Default config bugs do not generate GLSAs.
Auditing
Vulnerabilities that are found by Gentoo developers should be double-checked before going out in the open (to upstream developers or security lists). They are filed as Confidential Bugs (see below) and with the Auditing component. When the finding has been verified they are switched to Vulnerability .
Restricted bugs
Sometimes a bug is communicated to us under the promise we'll keep it secret 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 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).
There are three different types of restricted bugs. The first (and most secret) ones are the CLASSIFIED bugs. A bug is classified when it contains information that should never be released. This includes quotes of personal emails sent to restricted mailing-lists or non-public intermediary patches. Classified bugs are identified by the CLASSIFIED keyword in their Status Whiteboard. Once CLASSIFIED, a bug cannot go back to unclassified status unless at least two security managers agree to declassify it. CLASSIFIED bugs should never be opened (unrestricted).
The second type of restricted bugs is CONFIDENTIAL bugs. These are bugs that contain information that should be kept secret until an agreed-upon coordinated release date. No part of the bug (affected package name, description, proposed patch or whatever) should ever leak outside the bug. Patches must NOT be committed to portage CVS.
The third (and less secret) type of restricted bugs is the SEMI-PUBLIC bugs. Semi-public bugs should be kept secret, but patches may be committed to portage. This is generally when the vulnerability is not known to the general public but could be accessed by anyone (patch in upstream CVS for example).
Public vulnerability bug management
Bug summary rules
The bug summary has two formats depending on the whiteboard status.
When no fixed version is in the Portage tree (whiteboard is [upstream] or [ebuild]), versions should be omitted until a stable candidate has been identified. In this instance, the summary syntax will be:
category/package_name: Description of Vulnerability or Impact (CVE...)When a stable candidate or fixed version is available in Portage (whiteboard is [stable], [glsa], or [cleanup]), the bug title is changed to indicate which versions of the package are vulnerable. In this instance, the bug summary syntax will be:
<category/package_name-first_fixed_version: Description of Vulnerability or Impact (CVE...)
There should not be a space between the package name or version and the colon following it.
Multiple packages with similar names can be grouped in the bug summary using braces. This is commonly used with binary packages. For example, Mozilla products are also available as a binary package. This is listed in the bug summary as:
<mail-client/thunderbird{,-bin}-24.3, <www-client/firefox{,-bin}-24.3, <www-client/seamonkey{,-bin}-2.24: Multiple vulnerabilities
Another example is the Oracle JRE and Oracle JDK packages, where the middle of the package name is different:
<dev-java/oracle-{jdk,jre}-bin-1.7.0.45: Multiple vulnerabilities
Multiple CVE references in a single bug can be grouped in the summary by year. For example, the Oracle JRE and Oracle JDK January 2014 Critical Patch Update included CVE references from 2013 and 2014. These can be grouped in the bug summary as follows:
{{GenericCmd|<dev-java/oracle-{jre,jdk}-bin-1.7.0.51: multiple vulnerabilities (CVE-2013-{5902,5904,5905,5906,5907,5910},CVE-2014-{0368,0373,0375,0376,0382,0385,0387,0403,0408,0410,0411,0415,0416,0417,0418,0422,0423,0424,0428})}}
Multiple fixed slots for a single package can be grouped in the bug summary after the package name. For example, Wireshark has 1.8.x and 1.10.x stable branches. When a fixed version of each slot is in the Portage tree, it can be noted in the bug summary as follows:
{{GenericCmd|<net-analyzer/wireshark-{1.8.12,1.10.5}: multiple vulnerabilities (CVE-2013-{7112,7113,7114})}}
See the next section for more about status whiteboard rules.
Status whiteboard rules
The status whiteboard in Bugzilla lets us keep track of the security bug resolution steps. It should be following this pattern: "RATING [status] coordinator", where:
| Element | Content | Example |
|---|---|---|
| RATING | The vulnerability rating, following current policy rules | B3 |
| [status] | The bug status, with optional extra information | [ebuild] |
The following statuses are accepted:
| Status | Description |
|---|---|
| upstream | Waiting for upstream developer to publish a new version or patch |
| ebuild | Waiting for the Gentoo package maintainer to provide a fixed ebuild |
| upstream/ebuild | Still waiting for upstream developer, however there's also a fix available (patch, workaround ...) which could be integrated into the ebuild to address this vulnerability |
| stable? | A stable candidate has been identified. Awaiting maintainer confirmation to start stabilization |
| stable | Waiting for arches to mark the package with the appropriate keywords |
| glsa? | Security must make a decision on whether a GLSA is needed |
| glsa | Waiting for the coordinator to send his GLSA |
| glsa+ | The GLSA has been sent |
| noglsa | The bug does not require a GLSA (~arch only or voted to not have a GLSA) |
| cleanup | Waiting for the Gentoo package maintainer to remove vulnerable ebuilds from the tree |
The following extra information is admitted:
| Extra information | Description | Corresponding statuses |
|---|---|---|
| blocked | When the bug is blocked by another bug | (any) |
| cve | A member of the Security project has assigned applicable CVE(s) to the bug in CVETool | (any) |
Examples:
| C0 [stable] |
| B1 [stable blocked] |
Determining original bug status
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 a fix is available, the bug is in [ebuild] status. If a fixed ebuild is put in the Portage tree, the next step is stabilizing, so the bug is in [stable] 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 [glsa] status. Is the bug not severe enough, GLSA voting is next, so the status would be [glsa?] .
Bugs in [upstream] status
In [upstream] 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, 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. For example, it would be reasonable to compare the patch with the patches (if any) that have been picked up by other distributions. When a fix version is announced or it appears that upstream will not fix the bug while there are publicly acceptable patches, the bug enters [ebuild] status.
Bugs in [ebuild] status
In [ebuild] status, we must identify the maintainer of the package, and summon them to commit a fixed ebuild. You should add all maintainers for the package to the bug and ask them 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.
If the maintainer doesn't show up, it is allowed for security to bump the package. 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. Note that the typical standards for ebuilds in the Gentoo repository still apply. After developing a patch for the Gentoo repository to fix the vulnerability, one should open a pull request to apply the patch, taking care to appropriately tag the bugs in the commit messages.
Bugs in [stable] status
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 equally or more stable keywords than any other packages in Portage. Here is an example:
| Versions | Keywords |
|---|---|
| Affected | x86 ~ppc ~ia64 |
| Affected | x86 ppc |
| Affected | ~x86 ~ppc ~ia64 |
| Fix must have: | x86 ppc ~ia64 |
You can use http://packages.gentoo.org to help you determine the needed KEYWORDS. If affected packages were removed by the package maintainer too early, you should use our ViewVC to dig in the Attic and look for old KEYWORDS.
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 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.
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 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 option is to security-mask the package: there is no acceptable unaffected version, so it is like if no acceptable upstream fix was provided.
Due to the high email volumes created by security bugs, Arch Testers who mark packages stable on multiple architectures should only notate the security bug ONCE containing all arches they marked stable.
Bugs in [glsa] status
After stabilization, if the security bug is corrected and the severity of the bug requires a GLSA, the status becomes [glsa]. A GLSA request should be filed in GLSAMaker. The bug remains open until the GLSA is published.
There are also cases where a vote must take place to decide if a GLSA is needed ([glsa?] status). A Security Team member will review the vulnerability and in case they decide that a GLSA is not needed, the bug status becomes [noglsa]. Any vulnerable versions should be removed from Portage, then the bug can be closed as FIXED without releasing a GLSA.
Until early 2016, votes of at least two members of the Security Team were required to make this decision. As these votes were usually unanimous, we agreed that one vote is now sufficient in order to save manpower.
The Security team does not release GLSA's for Cross Site Scripting (XSS) vulnerabilities. If the bug contains only the Cross Site Scripting vulnerability, the bug status after stabilization can become [noglsa]. Any vulnerable versions should be removed from Portage, then the bug can be closed as FIXED without releasing a GLSA.
For bugs where the severity is trivial, the bug status after stabilization can become [noglsa]. Any vulnerable versions should be removed from Portage, then the bug can be closed as FIXED without releasing a GLSA.
When a GLSA is needed but nothing was sent, the bug enters [glsa+] 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.
Bugs in [cleanup] status
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.
For example, the foo 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 [glsa] or [glsa?] depending on severity.
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 [cleanup] 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.
Confidential vulnerability bug management
Status whiteboard rules
Confidential bugs should be following this pattern: RATING [status] KEYWORD CRD , where:
| Element | Content | Example |
|---|---|---|
| RATING | The vulnerability rating, following current policy rules | B3 |
| [status] | The bug status, with optional extra information | [ebuild] |
| KEYWORD | The confidentiality level of the bug, can be CLASSIFIED, CONFIDENTIAL, SEMI-PUBLIC | CLASSIFIED |
| CRD | The coordinated release date for the bugs disclosure. If no time is given, assume 14:00 UTC. | 2009-01-06 18:00 UTC |
The following extra statuses are accepted in confidential bugs:
| Status | Description |
|---|---|
| preebuild | Specific package maintainer has been called to prepare an ebuild which must not be committed in the CVS tree, but attached to the bug |
| prestable | Specific arch testers has been called to test a not-yet-public ebuild |
Handling confidential bugs
Semi-public bugs should be handled as public bugs, except that no herd or arch alias should be CC-ed on the bug but rather specific developers.
Confidential and classified bugs need extra care. The ebuild and files fixing 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 or shortly after the issue goes public.
GLSA drafting with GLSAMaker
General rules
The GLSA should use the affected software name with proper capitalization, not the Gentoo package name. For example, you should use "MySQL" and not "mysql". Lowercase names should be used only if the software has an all-lowercase name or if the software is identified by its command name ("traceroute").
You should not copy any part of any existing advisory, but you may use them as sources of information for our GLSA. If you copy, for example a software description, from a website, please use a citation and quotes.
Title, Synopsis, Keywords
The title must be short (< 60 characters in most cases) and have the application name (not category) in front. It should clearly identify the impact, without getting into any details. Version should be left out, except in rare cases where it allows to identify the package more clearly. Multiple affected packages should be separated by a comma. Examples include:
| MySQL: Data loss |
| Exim: Denial of Service |
| Apache 1.3: Arbitrary code execution |
| MPlayer, xine-lib: Multiple vulnerabilities |
Synopsis is a short (< 160 characters), but complete, description of the vulnerability. People reading only the Synopsis should get a good idea what the vulnerability is and what impact it has. Examples include:
| Two MySQL utilities create temporary files with hardcoded paths, allowing an attacker to use a symlink to trick MySQL into overwriting important data. |
| Multiple vulnerabilities, including remotely exploitable buffer overflows, have been found in code common to MPlayer and the xine library. |
The GLSA keyword category is typically set to "Ebuild" and should contain the name of the main software vulnerable (for example, "MySQL"). Other keyword types include "Portage" (for portage bugs) and "Infrastructure" (for server compromises).
Access, Severity
Access should be "Local" or "Remote". Local vulnerabilities can be carried out only by a local user of the system. For example it implies to run a specific executable to elevate privileges, or access to a temporary directory to run a symlink attack. Remote vulnerabilities are those that can be exploited by an attacker with or without an account on the system. Remote vulnerabilities can either be active (exploiting a listening server by sending malicious queries) or passive (enticing a user to connect client software to a malicious server or to open malicious files).
Severity is an indication of how deep the vulnerability is. It is defined in the Vulnerability Treatment Policy, in the table "Evaluate the vulnerability type". Note that it depends only on the maximum risk, not on the commonality of the configuration option at risk. A buffer overflow allowing arbitrary code execution in a rare client software, only when it uses a specific configuration option, theoretically remains a "High" severity. A denial of service on all configurations of Apache theoretically remains a "Normal" severity. In rare cases the severity may be adjusted, when several members of the Security Team agree, to a more relevant level. For example, a vulnerability allowing defacement of web sites on Apache and all configurations should probably be "High" rather than "Normal".
Unaffected, Vulnerable packages
This section provides information about versions of packages that are unaffected or vulnerable to the vulnerability described in this advisory. You should pay special attention to those numbers as they are one of the few areas where mistakes imply an errata publication.
There are the different fields composing an version entry. The package name field must list the category and package name ("net-mail/exim"). Regarding the "Architectures" field, you should put "*" in it when the version description applies to all the arches marked in the ebuild. You should use multiple entries for different arches if the version description is different from arch to arch. The "Auto" field must be set to true if the package is upgradeable by emerge.
In this section (and only in this section), the architectures should be written as they appear in the KEYWORDS (i.e. "x86", "amd64", "sparc"...), and not in uppercase.
For version fields, there are multiple cases:
The simple case is when the vulnerability is present in all old versions, and is fixed in all versions newer than a specific fix version. In this case, you should use ">= first fixed version" as unaffected and "< first fixed version" as vulnerable. You should double-check that there was no ebuild between the last affected version and the first fixed version.
A more complex case is when the vulnerability is present only in a few recent versions. Let's take the example of a package where 1.2.8-r2 was not affected, 1.2.9, 1.2.9-r1 and 1.2.9-r2 were affected, and 1.2.10 is fixed. In this case there are two possibilities:
| Unaffected | Vulnerable |
|---|---|
| >=1.2.10 | ==1.2.9 ==1.2.9-r1 ==1.2.9-r2 |
| <=1.2.8-r2 >=1.2.10 | <1.2.10 |
Another complex case is when the vulnerability is present in multiple slots for a package. For example, a package may have versions 1.5.x as SLOT="0" and versions 1.2.x as SLOT="1.2". If a vulnerability exists in 1.5.8 and 1.2.46 and was fixed in 1.5.9 and 1.2.47, the unaffected and vulnerable versions would look like this:
| Unaffected | Vulnerable |
|---|---|
| >=1.5.9 *>=1.2.47 | <1.5.9 |
Some slotted packages require that the GLSA's Unaffected packages section be updated when a new version of a slot is released.
Finally, when the package has no fixed version, you should omit the "Unaffected" entry for that package and set "Auto" to "no".
When the fixed versions are complex, you should double-check that the XML and TXT versions of the GLSA list your versions correctly.
Background, Description, Impact
The Background section gives information about the package at risk. It describes briefly what it is and gives any information that is helpful in understanding the part of the package vulnerable. The Background section should be shorter than the Description section or the Impact section. Good examples include:
| The K Desktop Environment (KDE) is a powerful Free Software graphical desktop environment. KDE makes use of URI handlers to trigger various programs when specific URLs are received. |
| CVS (Concurrent Versions System) is an open-source network-transparent version control system. It contains both a client utility and a server. |
| Metamail is a program that decodes MIME encoded mail. It is therefore often automatically called when an email is received or read. |
The Description section details what the vulnerability is, without telling what happens when it is exploited. It should be understandable by people without too much security background. Sometimes there is no information about the vulnerability at all, in which cases you should let the description short. Good examples include:
| The telnet URI handler in Opera does not check for leading '-' characters in the host name. Consequently, a maliciously-crafted telnet:// link may be able to pass options to the telnet program itself. One example would be "telnet://-nMyFile" If MyFile exists in the user's home directory and the user clicking on the link has write permissions to it, the contents of the file will be overwritten with the output of the telnet trace information. If MyFile does not exist, the file will be created in the user's home directory. |
| The MySQL bug reporting utility (mysqlbug) creates a temporary file to log bug reports to. A malicious local user with write access to the /tmp directory could create a symbolic link of the name mysqlbug-N pointing to a protected file, such as /etc/passwd, such that when mysqlbug creates the Nth log file, it would end up overwriting the target file. A similar vulnerability exists with the mysql_multi utility, which creates a temporary file called mysql_multi.log. |
| Multiple vulnerabilities have been found and fixed in the RTSP handling code common to recent versions of these two packages. These vulnerabilities include several remotely exploitable buffer overflows. |
The Impact section describes the global impact of the vulnerabilities described in the Description section, when exploited. It should focus on the maximum risk. Multiple impacts should be listed from highest to lowest severity. Good examples:
| A remote attacker, posing as a RTSP stream server, can execute arbitrary code with the rights of the user of the software playing the stream (MPlayer or any player using xine-lib). Another attacker may entice a user to use a maliciously crafted URL or playlist to achieve the same results. |
| This vulnerability has two possible impacts. First, it may create new files in the user's home directory. Second, and far more serious, it may overwrite existing files that the user has write permissions to. An attacker with some knowledge of a user's home directory might be able to destroy important files stored within. |
Workaround, Resolution
The workaround describes if there is any simple way (other than upgrading to the fix version) of avoiding to be vulnerable. Good examples include:
| For a temporary workaround, providing you do not require Kerberos 4 support, you may turn off Kerberos 4 kadmin by running kadmind with the --no-kerberos4 option. |
| There is no known workaround at this time. |
The Resolution section explains in human-readable terms what you have to do to be fully protected against the vulnerability. This section must look like this:
All Heimdal users should upgrade to the latest stable version:
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-crypt/heimdal-0.6.2"
</code>
If there are multiple architectures, it should look like this:
OpenOffice.org users on the SPARC architecture should:
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.1.0-r3"
</code>
</p>
<p>
OpenOffice.org users on the PPC architecture should:
</p>
<code>
# emerge --sync
# emerge --ask --oneshot --verbose ">=app-office/openoffice-1.0.3-r1"
</code>
If the GLSA is about a shared library, you should include the following paragraph at the end of the Resolution section to warn about the necessity to rebuild linked executables:
| Packages which depend on this library may need to be recompiled. Tools such as revdep-rebuild may assist in identifying some of these packages. |
References
The References section should provide links to reference information about the vulnerability. When a CVE number (CVE-XXXX-XXX) is available, it should be provided (with the complete CVE number in "Title"). You can also link an upstream developer advisory and/or announce email, when available. You should avoid links to other distribution advisories or non-official advisories from separate entities.
GLSA publication
Peer reviewing
When the draft is finished, it must be submitted for review by other members of the Security Team, e.g. by calling for review on the #gentoo-security channel. The final version (after all corrections are made) must be approved by a least one Security Team member (other than the author) before being released and sent out. The author and reviewer may decide who of them carries out the release.
When reviewing a GLSA draft carefully check the correctness of the following things:
- Affected/unaffected versions (Check ChangeLog that versions are correct and make sure that there is no version not included by either affected or unaffected).
- Title correctness.
- Severity and Access (Don't just rely on the bug rating and for "Local" access a local account is needed otherwise it is "Remote").
- Finally do a sanity check: Is this a real vulnerability and not just a bug (like the Samba and Shadow non-vulnerabilities).
When the draft is approved, it must be assigned an official GLSA number. This is done by calling the "Move" function in GLSAMaker to move the draft from the pool to the official area.
GLSA XML commit
You need to commit the GLSA XML to the git repository. Pull, commit, push. Please use 'GLSA XXXX-XX' as commit message.
E-mail announcement
Whenever you use a new setup (software or machine) to post a GLSA announcement, you should get your setup checked by sending a test email to another member of the Security Team.
Click on the Txt download to have a text version of the GLSA. Check that the affected/unaffected section looks good, then prepare an email with the following rules:
- From and Return-Path must be set to yourname@gentoo.org
- To and Cc should be set according to policy
- Subject must be "[ GLSA XXXXYY-ZZ ] Your vulnerability here" (you should copy/paste from the title in the Txt file)
- the body of the mail should be the content of the Txt file, from the "Gentoo Linux Security Advisory" header to the end of the file
- email must be signed by the GPG key for your yourname@gentoo.org address
You will receive a return email from gentoo-announce telling it requires moderation. Just reply to it and the announce email will get through.
Bug closing
You should check that the email got through to gentoo-announce, then you can close the related bug(s), by setting their status to RESOLVED/FIXED , with a comment pointing to the GLSA number.
Errata/Update publication
An erratum is published when we made a mistake otherwise it is an update. When policy warrants a republication these guidelines should be followed:
- Revision should be correctly set in XML. This means that revision might need to be manually corrected in GLSAMaker data directory, if you do multiple changes using GLSAMaker ( ie. <revised>September 10, 2004: 02</revised>)
- If there is no vulnerability no affected packages should be listed in the XML
- Title can change ( ie. GLSA 200409-14 for Samba and GLSA 200411-01 for ppp)
- Not all Errata need republication. Policy details when republication is needed.
- For the text version GLSAmaker can add the relevant information to updates and erratas. Manually follow the instructions provided by GLSAmaker.
- Text version must contain an Errata or Update section (example shown below) and AFTER THAT only the sections changed (XML version does not have extra sections)
| This advisory incorrectly described ppp as being vulnerable to a remote denial of service. After further verifications, it appears that a remote user can only deny service to himself, so this bug does not induce any security issue at all. The corrected sections appear below. |
For two complete errata email examples see ERRATA: [ GLSA 200409-14 Samba: Remote printing non-vulnerability] (where there were no real vulnerability) and ERRATA: [ GLSA 200801-09 X.Org X server and Xfont library: Multiple vulnerabilities] (where the problem was not correctly fixed in the initial version). For an update example see UPDATE: [ GLSA 200410-30 GPdf, KPDF, KOffice: Vulnerabilities in included xpdf] (where the fix introduced another vulnerability).
Otherwise normal GLSA publication guidelines should be followed.
GLSA Coordinators Tools
Security project git repository
- The Security project's git repository contains several tools to collaboratively assess whether we are affected by new CVE identifiers, and tools to determine target keywords. Most tools directly interact with Bugzilla, making manual copy-pasting unnecessary.
This page is based on a document formerly found on our main website gentoo.org.
The following people contributed to the original document: Thierry Carrez, Sune Kloppenborg Jeppesen, Matthias Geerdsen, Robert Buchholz, Alex Legler
They are listed here because wiki history does not allow for any external attribution. If you edit the wiki article, please do not add yourself here; your contributions are recorded on each article's associated history page.