Re: diffutils-3.9 released [stable]

[Bob Proulx]

Jim Meyering wrote:
> Note that the announcement does include a standard SHA1 checksum.
> Given we're providing multiple ways to verify integrity, I'm not
> losing sleep over this.

The inclusion of a standard SHA1 checksum was good.  That verified
with no trouble.

The problem actually started back in 2021 with the automake release
announcement.

    https://lists.gnu.org/archive/html/autotools-announce/2021-10/msg00000.html

I was in a discussion and asked how to verify the checksums in that
message.  Because in that message both checksums are base64 encoded.

    Here are the compressed sources:
      https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.xz (1.6MB)
      https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.gz (2.3MB)
    ...
    Here are the SHA1 and SHA256 checksums:

    8B1YzW2dd/vcqetLvV6tGYgij9tz1veiAfX41rEYtGk  automake-1.16.5.tar.xz
    B70krQimS8FyUM4J7FbpIdY0OQOUPpnM9ju/BwXjRgU  automake-1.16.5.tar.gz

    Each SHA256 checksum is base64 encoded, instead of the
    hexadecimal encoding that most checksum tools default to.

I was looking at how to do it for that package when diffutils released
and had a slightly different format with SHA1 normal but SHA256 base64
encoded.  And since the diffutils announcement was current of course I
decided to jump in here while the paint was still drying and before
weeds could grow between the cracks of the pavement.

> > Simple is better!
>
> Hi Bob, I lean that way, too, and in fact think I did make many
> releases with signatures only and no checksum, but some people much
> prefer checksums, and the desire to provide a robust hash with a
> compact representation is what led to the current state.

Published checksums are good!  But only if people can actually use
them for verification.  Let's not go out of our way to make this too
hard for people to actually do.

> Sadly, nothing about gpg signature verification is simple these days,
> with keyserver problems everywhere.

There are some issues with gpg verification, sadly.

> For now, I'm stubbornly waiting for an improved cksum :-)

Why wait?  I am obstinately proposing that checksums be published in
the standard format so that they are easily accessible for anyone to
verify right now.  This has been done for years.  No need to wait for
a new flavor of checksum to appear.

Why are we fixated on creating a new and never before seen[1] base64
signature encoding?  Standard is better than better.  Let's use the
encoding that has been and so far continues to be standard.

Bob

[1] I know Amazon's AWS uses base64 encoding of checksums for some
aspects of its operation.  So me saying "never before seen" is
hyperbole.  Since I have seen it with Amazon.  Maybe I should say
instead, not a typical way to publish checksums.