Re: [PATCH v2] Update advisory format and introduce some automation

["Andreas K. Huettel" <dilfridge@gentoo.org>]

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

Am Mittwoch, 24. Januar 2024, 21:02:04 CET schrieb Siddhesh Poyarekar:
> 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>
> ---
> 

Some minor things below, otherwise good to go and

Reviewed-by: Andreas K. Hüttel <dilfridge@gentoo.org>



> +
> +  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.  For a simple release-version, e.g. 2.34, this
> +change is present in release tarballs.  For release-version of the form
> +2.34-NNN (e.g.  2.34-42), the change is on the release/2.34/master
> +branch and not in any released tarball.

Since this follows git-describe, I assume it means the 42th commit on the 
branch after the tag... Why not write that here?

> +Adding an Advisory
> +------------------
> +
> +An advisory for a CVE needs to be added in two steps:
> +
> +1. 

On the master branch, ...

> 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 add all commits to the advisory 

... on the master branch ...

> using
> +   the Fix-Commit tags.  Don't add the release-version subscript.
> +
> +3. Run the process-advisories.sh script in the scripts directory on the
> +   advisory:

[...]

> +
> +advisories_news() {
> +  rel=$(get_rel "HEAD")
> +  for f in $(grep -l "^Fix-Commit: .* ($rel)$" advisories/*); do
> +    echo -e "  $(basename $f):"
> +    cve_id=$(sed -n 's/CVE-Id: \(.*\)/\1/p' $f)

^ This assumes that every SA will ever have exactly one CVE.
Is that a safe assumption?

> +    echo "$(head -1 $f) ($cve_id)" | fold -w 68 -s |
> +      while read line; do
> +	echo "    $line"
> +      done
> +    echo
> +  done


-- 
Andreas K. Hüttel
dilfridge@gentoo.org
Gentoo Linux developer
(council, toolchain, base-system, perl, libreoffice)

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 981 bytes --]