bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Simon Josefsson
Subject: Re: announce-gen: Show an SHA256 sum that can be verified more easily
Date: Tue, 10 Dec 2024 11:03:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)

Bruno Haible via Gnulib discussion list <bug-gnulib@gnu.org> writes:

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

Thank you!  I pushed the attached patch to make it possible to use it
from cfg.mk like this:

announce_gen_args = --cksum-checksums

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

These are good arguments, but to me they are outweighted by 1) having
shorter strings for readability and avoiding line wrapping and 2)
teaching users about good tools to use for this purpose.

>    In this case, "easy" means also "easy to remember". Doing
>      $ sha256<TAB>
...
> 2) Look what commands are available on various OSes:

Compare this announcement:

https://lists.gnu.org/archive/html/info-gnu/2024-11/msg00002.html

It has instructions on how to verify the download:

  Here are the SHA1 and SHA256 checksums:

  77227188ead223ed8ba447301eda3761cb68ef57  libtool-2.5.4.tar.gz
  2o67LOTc9GuQCY2vliz/po9LT2LqYPeY0O8Skp7eat8=  libtool-2.5.4.tar.gz
  9781a113fe6af1b150571410b29d3eee2e792516  libtool-2.5.4.tar.xz
  +B9YYGZrC8fYS63e+mDRy5+m/OsjmMw7rKavqmAmZnU=  libtool-2.5.4.tar.xz

  Verify the base64 SHA256 checksum with cksum -a sha256 --check
  from coreutils-9.2 or OpenBSD's cksum since 2007.

With your recent gettext 0.23 announcemnt:

https://lists.gnu.org/archive/html/info-gnu/2024-12/msg00000.html

  Here are the SHA1 and SHA256 checksums:

  File: gettext-0.23.tar.gz
  SHA1 sum:   c31ae593a7c51f805645914ca206991e072760d9
  SHA256 sum: 945dd7002a02dd7108ad0510602e13416b41d327898cf8522201bc6af10907a6

There are no instructions in the e-mail how to use the hashes.  The data
in the e-mail is not accepted by any tool that I know of without
reformatting.

Arguable, we could describe how to use 'sha1sum' to verify the SHA1
value.  But I think the current text with only 'cksum' is reasonable:
the set of people who do not know about 'sha1sum' but knows how to use
'cksum -a sha256' is probably empty.  If someone doesn't know either
tool, teaching them to use SHA256 directly is better, and there is no
need to ever have to learn about sha1sum (or they could learn 'cksum -a
sha1 --check' instead).

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

We already have Blake2 and SHA3.  The problem with cryptographic hashes
is that we may wake up tomorrow finding SHA256 unacceptable, and having
to do something about it urgently.  We are not likely to care about
solving this small cosmetic problem then.  It make sense to introduce
new algorithms selectively and continously, rolling out old ones as they
become less reliable (like SHA1).  I don't have hope we will ever see
the end of this continuous migration.  Teaching users about good
patterns during quiet times like now make them already trained if we
urgently have to deploy SHA4 and get it into 'cksum'.

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

Another analogy could be the migration from 'gzip -cd FOO | tar xf -' to
'tar xfz FOO' to 'tar xfa FOO'.

/Simon
From 563046ab9b3208b4b6df650451bb888fbbffc073 Mon Sep 17 00:00:00 2001
From: Simon Josefsson <simon@josefsson.org>
Date: Tue, 10 Dec 2024 09:52:37 +0100
Subject: [PATCH 1/2] maintainer-makefile: Pass on $(announce_gen_args) to
 announce-gen.

* top/maint.mk (announce_gen_args): New variable, for cfg.mk use.
(announcement): Use it.
---
 ChangeLog    | 6 ++++++
 top/maint.mk | 5 ++++-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 54546f10c9..09ac44d1c7 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2024-12-10  Simon Josefsson  <simon@josefsson.org>
+
+       maintainer-makefile: Pass on $(announce_gen_args) to announce-gen.
+       * top/maint.mk (announce_gen_args): New variable, for cfg.mk use.
+       (announcement): Use it.
+
 2024-12-09  Bruno Haible  <bruno@clisp.org>
 
        xstrtol-error: Use the translation domain "gnulib".
diff --git a/top/maint.mk b/top/maint.mk
index a6f130d3d6..b2baa02edf 100644
--- a/top/maint.mk
+++ b/top/maint.mk
@@ -1550,6 +1550,8 @@ announcement_mail_headers_alpha =         \
 announcement_mail_Cc_beta = $(announcement_mail_Cc_alpha)
 announcement_mail_headers_beta = $(announcement_mail_headers_alpha)
 
+announce_gen_args ?=
+
 announcement_Cc_ ?= $(announcement_Cc_$(release-type))
 announcement_mail_headers_ ?= $(announcement_mail_headers_$(release-type))
 announcement: NEWS ChangeLog $(rel-files)
@@ -1571,7 +1573,8 @@ announcement: NEWS ChangeLog $(rel-files)
            --bootstrap-tools=$(bootstrap-tools)                        \
            $$(case ,$(bootstrap-tools), in (*,gnulib,*)                \
               echo --gnulib-version=$(gnulib-version);; esac)          \
-           $(addprefix --url-dir=, $(url_dir_list))
+           $(addprefix --url-dir=, $(url_dir_list))                    \
+           $(announce_gen_args)
 
 .PHONY: release-commit
 release-commit:
-- 
2.46.0

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]