Re: Need better release validation documentation/strategy.

[Carlos O'Donell]

On 4/8/22 09:30, Bob Friesenhahn wrote:
> Today I saw an announcement for a new version of gzip.  It provided
> lots of data for how to verify the downloaded tarballs.  I recently
> saw a very similar announcement for a new version of libtool. I am
> not sure where the template of this announcement text is coming from,
> and if anyone has validated that recipients will be able to make
> sense of it.

We make no such statements for glibc, and it's arguably more central to any
whole system validation that you're making.

However, because of the requirements for gpg signatures to upload to the FSF
servers we end up with a signature against the uploaded binary from the GNU 
Project
maintainer.

You can verify that I uploded glibc 2.35 to the FSF servers, and you have to
have a web of trust for me:

gpg --verify glibc-2.35.tar.xz.sig glibc-2.35.tar.xz
gpg: Signature made Thu 03 Feb 2022 01:35:30 AM EST
gpg:                using RSA key ...
gpg: Good signature from "Carlos O'Donell <carlos@systemhalted.org>"
gpg:                 aka "Carlos O'Donell (Work) <codonell@redhat.com>"
gpg:                 aka "Carlos O'Donell (Work) <carlos@redhat.com>"

> It seems like Automake and GNU in general should be trying to help
> with producing releases and release announcements which assist users
> with verifying the release tarballs rather than just leaving them
> royally confused.

In general this is documented here for the GNU Project:

Information for maintainers of GNU software
https://www.gnu.org/prep/maintain/

> I am not sure who the target audience is for GNU releases these days,
> but if it is not normal people who are still willing to compile
> software from source code on popular systems such as GNU/Linux, then
> there is a problem.

Can you expand a bit on the problem that you see?

-- 
Cheers,
Carlos.