Re: announce-gen: Show an SHA256 sum that can be verified more easily

[Bruno Haible]

Jim Meyering wrote:
> > I think we should encourage people to use 'cksum' rather than
> > 'sha256sum' since the latter is a bad pattern that leads to an explosion
> > of tools when new hash algorithms are introduced.
> 
> I too prefer the shorter checksums and would like to encourage the use
> of the more compact representation by making that the default. Not
> just to keep line lengths under 80 columns, but just generally to
> minimize the noise of checksums in announcements.

OK, clearly there are different preferences. So, let me restore the
previous behaviour through a command-line option: --cksum-checksums.

Here's why I believe that hex as the default is the better choice:

1) When end users are responsible for adopting a secure behaviour,
   you need to make it easy for them, otherwise they will just skip the
   secure behaviour.
   Examples:
     - PGP and S/MIME are accepted by users when integrated into the
       mail client, without need for configuration; otherwise not.
     - When downloading an ISO 9660 image, if you need to explain them
       how to verify the integrity of the download in a lengthy way,
       most users will just not do it.
     - Online banking with a separate TAN device is more secure than
       by using a smartphone. But that TAN device is not the default
       and costs extra money.

   In this case, "easy" means also "easy to remember". Doing
     $ sha256<TAB>
   command completion is the easiest one. 'cksum' with two options
   is not.

2) Look what commands are available on various OSes:

GNU, Cygwin (coreutils)   sha256sum FILE, cksum -a sha256 FILE
Alpine Linux (BusyBox)    sha256sum FILE                (cksum does only CRC32)
macOS                     shasum -a 256 FILE            (cksum does only CRC32)
FreeBSD                   sha256sum FILE, sha256 FILE   (cksum does only CRC32)
NetBSD                    sha256 FILE, cksum -a sha256 FILE
OpenBSD                   sha256 FILE, cksum -a sha256 FILE
AIX 7                     shasum -a 256 FILE            (cksum does only CRC32)
Solaris 11                sha256sum FILE                (cksum does only CRC32)
Native Windows            CertUtil -hashfile FILE SHA256
Also:                     openssl dgst -sha256 FILE

   Obviously, sha256<TAB> works best on all OSes, except native Windows.

   On five of the platforms, cksum does only CRC32; thus, users would not
   only have to remember the 'cksum' command with options, to use with GNU
   coreutils, but also to remember that it does not work everywhere.

3) Your arguments, Simon and Jim, refer to the future: "when new hash
   algorithms are introduced".

   When will that be? When do you expect that SHA256 sums will be
   insufficient? In 5 years or 10 years, maybe?

   Then, what is the point of letting users to complex things _now_
   and in the next 5 or 10 years — and thus, as explained above, have
   many users skip the procedure entirely —, when this is not needed yet?

   It's like saying "the gunzip program is redundant, we would prefer
   everyone to learn to use 'gzip -d' instead". Or "the fgrep program
   is redundant. we would prefer everyone to use 'grep -F' instead";
   such a move has shown to not sit well with users.

4) > encourage the use
   > of the more compact representation by making that the default

   Before doing that, I claim, we would need that more compact
   representation available across OSes (see point 2 above) *first*.
   Then it would make sense to make it the default.

5) > Not just to keep line lengths under 80 columns

   The hex representation first under 80 columns. So, this is a strawman
   argument.

   Also, if you want to prepare for better algorithms in 5 or 10 years,
   then wouldn't it be SHA512? But an SHA512 sum needs 2 80-columns
   lines anyway (128 characters in one case, 88 characters in the other
   case). So, you effectively win nothing from the base64 output.

Bruno

0001-announce-gen-Add-option-cksum-checksums.patch
Description: Text Data