mirror of
git://sourceware.org/git/glibc.git
synced 2024-12-21 04:31:04 +08:00
443c10018c
Simplify the advisory format by dropping the -Backport tags and instead stick to using just the -Commit tags. To identify backports, put a substring of git-describe into the release version in the brackets next to the commit ref. This way, it not only identifies that the fix (or regression) is on the release/2.YY/master branch, it also disambiguates regressions/fixes in the branch from those in the tarball. Add a README to make it easier for consumers to understand the format. Additionally, the Release wiki needs to be updated to inform the release manager to: 1. Generate a NEWS snipped from the advisories directory AND 2. on release/2.YY/master, replace the advisories directory with a text file pointing to the advisories directory in master so that we don't have to update multiple locations. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>
74 lines
2.6 KiB
Plaintext
74 lines
2.6 KiB
Plaintext
GNU C Library Security Advisory Format
|
|
======================================
|
|
|
|
Security advisories in this directory follow a simple git commit log
|
|
format, with a heading and free-format description augmented with tags
|
|
to allow parsing key information. References to code changes are
|
|
specific to the glibc repository and follow a specific format:
|
|
|
|
Tag-name: <commit-ref> (release-version)
|
|
|
|
The <commit-ref> indicates a specific commit in the repository. The
|
|
release-version indicates the publicly consumable release in which this
|
|
commit is known to exist. The release-version is derived from the
|
|
git-describe format, (i.e. stripped out from glibc-2.34.NNN-gxxxx) and
|
|
is of the form 2.34-NNN. If the -NNN suffix is absent, it means that
|
|
the change is in that release tarball, otherwise the change is on the
|
|
release/2.YY/master branch and not in any released tarball.
|
|
|
|
The following tags are currently being used:
|
|
|
|
CVE-Id:
|
|
This is the CVE-Id assigned under the CVE Program
|
|
(https://www.cve.org/).
|
|
|
|
Public-Date:
|
|
The date this issue became publicly known.
|
|
|
|
Vulnerable-Commit:
|
|
The commit that introduced this vulnerability. There could be multiple
|
|
entries, one for each release branch in the glibc repository; the
|
|
release-version portion of this tag should tell you which branch this is
|
|
on.
|
|
|
|
Fix-Commit:
|
|
The commit that fixed this vulnerability. There could be multiple
|
|
entries for each release branch in the glibc repository, indicating that
|
|
all of those commits contributed to fixing that issue in each of those
|
|
branches.
|
|
|
|
Adding an Advisory
|
|
------------------
|
|
|
|
An advisory for a CVE needs to be added on the master branch in two steps:
|
|
|
|
1. Add the text of the advisory without any Fix-Commit tags along with
|
|
the fix for the CVE. Add the Vulnerable-Commit tag, if applicable.
|
|
The advisories directory does not exist in release branches, so keep
|
|
the advisory text commit distinct from the code changes, to ease
|
|
backports. Ask for the GLIBC-SA advisory number from the security
|
|
team.
|
|
|
|
2. Finish all backports on release branches and then back on the msater
|
|
branch, add all commit refs to the advisory using the Fix-Commit
|
|
tags. Don't bother adding the release-version subscript since the
|
|
next step will overwrite it.
|
|
|
|
3. Run the process-advisories.sh script in the scripts directory on the
|
|
advisory:
|
|
|
|
scripts/process-advisories.sh update GLIBC-SA-YYYY-NNNN
|
|
|
|
(replace YYYY-NNNN with the actual advisory number).
|
|
|
|
4. Verify the updated advisory and push the result.
|
|
|
|
Getting a NEWS snippet from advisories
|
|
--------------------------------------
|
|
|
|
Run:
|
|
|
|
scripts/process-advisories.sh news
|
|
|
|
and copy the content into the NEWS file.
|