Re: RFC: cksum --base64/-b support

[Jim Meyering]

On Mon, Jan 30, 2023 at 10:17 AM Pádraig Brady <P@draigbrady.com> wrote:
> On 29/01/2023 20:40, Jim Meyering wrote:
> > Hi Pádraig! Happy new year (belatedly ;-). Hope you're well.
> >
> > I'd like our generated announcements to be able to include
> > base64-encoded checksums without having to recommend verifying them
> > using openbsd's cksum, so...

Thanks for the long reply.

> This is so the checksums are shorter right?

That was my primary motivation.

> I.e. 4x/3 rather than the 2x for hex.
> Playing devil's advocate, is the complexity of
> generally using base64 for this worth it, since say a 512 bit checksum
> would only reduce from 128 chars to 86 chars?

IMHO, added complexity is small, so yes, it's worth it.

> Also related to this is the use of variable length algorithms
> (supported with the existing -l option).
> A quick scan of https://www.keylength.com/ suggests newer algorithms
> like blake2 blake3 sha3 with -l 256 may be sufficient for this use case
> in which case the difference would only be 64 chars to 44 chars.
> The following demos that, while also using existing tools:
>
>    $ sha256sum < /dev/null | xxd -r -p | basenc --base16
>    E3B0C44298FC1C149AFBF4C8996FB92427AE41E4649B934CA495991B7852B855
>    $ sha256sum < /dev/null | xxd -r -p | basenc --base64
>    47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
>
> > I've begun writing the code to add --base64/-b support for GNU cksum,
> > prompted by this thread:
> > https://lists.gnu.org/r/diffutils-devel/2023-01/msg00015.html and the
> > fact that OpenBSD already has this option (as -b):
> > https://man.openbsd.org/cksum
>
> We originally considered this back at:
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=7313
> which showed ways to achieve this with existing tools.
> Though if it was a common operation (like it would be for your use case),
> and for the fact that openbsd already implements this,
> then it would be worth adding an option.
>
> BTW I noted the following possible option when I recently refactored cksum:
>
>    --digest_format={int, hex, base64, binary}
>        /* cksum output formats:
>           int (sum, and cksum default),
>           hex (rest default),
>           b64 (to reduce size),
>           bin (would auto suppress names? restrict to single argument? */

I'm not sure how --digest-format=int -a sha1 would work.
Or --digest-format=bin -a sum

But doing it that way does provide a way to override a prior --base64 option.
Without that, is a --hex option warranted?