Re: diffutils-3.9 released [stable]

[Bob Proulx]

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

> The missing '=' was intentional but can always be discussed.  Since the
> hash size is fixed, the base encoding padding character is not important
> and looked ugly to me.  I think the tool should support both string with
> and without the padding.

The problem with that is that this deviates from long standing
practice.  The standard tools can't be used to decode it without
modifying it to have the padding characters.

Bob