Re: diffutils-3.9 released [stable]

[Jim Meyering]

On Mon, Jan 16, 2023 at 9:52 PM Bob Proulx <bob@proulx.com> wrote:
>
> Simon Josefsson wrote:
> > >> What useful base64 sha256sum utility am I missing?
> > Yes that is a good question -- base64-support should be added to
> > digest.c in my opinion.
> >
> > For hash checking I believe base64 formats should work automatically
> > with -c as well and not need any other command-line parameter.
>
> I think this means that there is currently no utility that will do
> this checking at this time?  The base64 sha256sum lines in the release
> notes are purely cosmetic?  Oh that's not good.  :-(
>
>     $ echo 2A076QogGGjeg9eNrTQTrYgWDMU7zDbrnq98INvwI/E diffutils-3.9.tar.xz | 
> sha256sum -c
>     sha256sum: diffutils-3.9.tar.xz.sha256.base64: no properly formatted 
> checksum lines found
>
> I double checked and it does not exist now.  All along seeing those
> hashes in various releases I had simply thought there was a utility I
> did not know about.  Finding out that no such utility exists makes
> including those in the release announcements icky.
>
> If people are going to be expected to convert the base64 hashes to hex
> so that the current tools can verify it then I think instructions on
> how this should be done need to be provided in the release notes too.
> But then of course just providing the standard sha256sum hash would be
> better.
>
> > To generate base64-encoded hashes, a new parameter like -e,--base64
> > seems relevant.  Other thoughts on how the interface should be?
> >
> > Should we support this for the non-cksum tools?  One aspect is code
> > size: maybe it is okay to increase cksum with base64-support but let the
> > old tool sha256 not link to to base64 -- I haven't checked how things
> > are implemented, maybe having different approaches for different tools
> > is complicated.  If so, having the same support in cksum and sha256 is
> > simplest.
>
> This feels like a solution looking for a problem.  The only reason the
> utility needs to be created is because that's the hash signature being
> posted creates the problem.  A better solution would be to post
> standard hash signatures and then there would be no problem to solve.
>
> Also right now every other current operating system has a way to check
> the standard hex hash.  But none of them will have this new base64
> proposed utility for several release cycles.  Even if a new utility or
> option were created I think the standard hashes should be included for
> several years until other operating systems can catch up.  But forcing
> them to include this seems awful too.

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.

> Note that other release announcements from other utilities avoid the
> problem of manually verifying sha*sum by relying entirely upon gpg to
> verify the signature.  That also seems like a reasonable solution.
> Perhaps the best one.  For example this one.
>
>     
> https://lists.gnu.org/archive/html/autotools-announce/2021-01/msg00000.html
>
> 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.

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

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