[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Need better release validation documentation/strategy.

From: Bob Friesenhahn
Subject: Re: Need better release validation documentation/strategy.
Date: Fri, 8 Apr 2022 12:11:04 -0500 (CDT)
User-agent: Alpine 2.20 (GSO 67 2015-01-07)

On Fri, 8 Apr 2022, Jim Meyering wrote:

On Fri, Apr 8, 2022 at 6:30 AM 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

The problem is that the advice in the announcements regarding use of
'gpg' just doesn't work (commands fail),

That was my mistake, and I fixed it last night. We updated the
generated and recommended gpg-key-fetching command to be a wget
command that fetches from savannah. I presumed that it would just
work, but that was not true. I fixed it by adding my gpg key in the
"public information" section of each project for which I'm already
listed as an authorized uploader.

For some reason key servers are not very helpful these days with some of them offering distorted behavior or appearing to be severely overloaded. It may be that the key server used by default by Ubuntu Linux imposes additional limitations such as regarding exposing email addresses. The user might need to know how to specify a different server and know which ones to use.

This one failed:

% gpg --locate-external-key
gpg: error retrieving '' via WKD: General error
gpg: error reading key: General error

and this one confusingly did not succeed:

% gpg --recv-keys 7FD9FCCB000BEEEE
gpg: key 7FD9FCCB000BEEEE: new key but contains no user ID - skipped
gpg: Total number processed: 1
gpg:           w/o user IDs: 1

% gpg --verify gzip-1.12.tar.xz.sig
gpg: assuming signed data in 'gzip-1.12.tar.xz'
gpg: Signature made Thu 07 Apr 2022 11:59:54 AM CDT
gpg:                using RSA key 155D3FC500C834486D1EEA677FD9FCCB000BEEEE
gpg: Can't check signature: No public key

The next problem is this:

% sha256sum --version
sha256sum (GNU coreutils) 8.30
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Ulrich Drepper, Scott Miller, and David Madore.

It is possible that newer versions of this utility do support the base64 output but this one does not appear to. This is from Ubuntu 20.04LTS, which is Ubuntu's current LTS offering.

For the recent libtool announcement, the gpg issues were not identical but it was also not possible to retrieve the key using the instructions provided. The libtool maintainer tried and he was not able to get the instructions to work either.

It is definitely preferable to verify using gpg so anything which makes this easier for users.

I did post my mail to the Automake list since it seems that Automake may be able to help make some of these aspects better by providing helpful rules and boiler-plate pertaining to signing files and verifying that it is possible to validate the signature.

For GraphicsMagick I added rules to so that if I am doing a "release" (a distcheck plus a few more steps) the build automatically signs the release file and generates sha256 sums.

Bob Friesenhahn,
GraphicsMagick Maintainer,
Public Key,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]