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

[Siddhesh Poyarekar <siddhesh@sourceware.org>]

On 2024-01-27 18:54, Andreas K. Huettel wrote:
> 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>

Thanks! I'm sending out a v3 with your suggested changes.

> 
> 
>> +
>> +  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?

Ack, will do.

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

OK.

> 
>> 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 ...

OK.

>> 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 ...

OK.

>> and then add all commits to the advisory
> 
> ... on the master branch ...

OK, I've reworded it a bit.

>> 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?

Yes, we'll maintain a 1:1 correspondence between GLIBC-SA- and CVE-.

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

Thanks,
Sid