#874029 [uscan] Please support verification against a signed file of hashsums

Package:
devscripts
Source:
devscripts
Description:
scripts to make the life of a Debian Package maintainer easier
Submitter:
Jérémy Lal
Date:
2026-02-08 16:01:02 UTC
Severity:
wishlist
#874029#5
Date:
2017-09-02 07:58:43 UTC
From:
To:
The typical example i have under the hand is:
https://nodejs.org/dist/v6.3.1/
https://nodejs.org/dist/v6.3.1/SHASUMS256.txt
https://nodejs.org/dist/v6.3.1/SHASUMS256.txt.asc

As far as i remember it's not the only upstream distributing
a list of signatures.

Jérémy
#874029#10
Date:
2017-09-02 17:54:12 UTC
From:
To:
The subject confused me a bit.  This appears to be a list of the hashes
of each file, and this list of hashes is signed.  That's quite different
than the current signature handling, which expects a signature of the
archive and verifies the archive against that signature.

Cheers,
#874029#15
Date:
2017-09-02 18:19:15 UTC
From:
To:
2017-09-02 19:54 GMT+02:00 James McCoy <jamessan@debian.org>:


Indeed ! Hence the feature request !

Jérémy
#874029#22
Date:
2017-09-03 15:42:34 UTC
From:
To:
control: severity -1 wishlist


Hi,
this type.

Once we get the basic signature handling right, I may consider this.
But uscan is already too complicated since it added features
piece-by-piece.  I am very reluctant to add feature to support corner
cases.  This is low priority.

Priority as I think now:
 #1) Get documented features to work right all the way to orig.tar.gz
     (URL scanning seems to work but ...)
 #2) Support git repo as upstream URL
 #3) Make code more modular and readable
 #4) Flexible modular features
      * multiple upstream sites (look 2 sites and pick)
      * signature handling  (hush->sig etc.)
      * custom mk-origtargz (repack)
      * custom uupdate      (update source tree)

Regards,

Osamu
#874029#27
Date:
2017-09-03 15:42:34 UTC
From:
To:
control: severity -1 wishlist


Hi,
this type.

Once we get the basic signature handling right, I may consider this.
But uscan is already too complicated since it added features
piece-by-piece.  I am very reluctant to add feature to support corner
cases.  This is low priority.

Priority as I think now:
 #1) Get documented features to work right all the way to orig.tar.gz
     (URL scanning seems to work but ...)
 #2) Support git repo as upstream URL
 #3) Make code more modular and readable
 #4) Flexible modular features
      * multiple upstream sites (look 2 sites and pick)
      * signature handling  (hush->sig etc.)
      * custom mk-origtargz (repack)
      * custom uupdate      (update source tree)

Regards,

Osamu
#874029#32
Date:
2017-09-03 15:42:34 UTC
From:
To:
control: severity -1 wishlist


Hi,
this type.

Once we get the basic signature handling right, I may consider this.
But uscan is already too complicated since it added features
piece-by-piece.  I am very reluctant to add feature to support corner
cases.  This is low priority.

Priority as I think now:
 #1) Get documented features to work right all the way to orig.tar.gz
     (URL scanning seems to work but ...)
 #2) Support git repo as upstream URL
 #3) Make code more modular and readable
 #4) Flexible modular features
      * multiple upstream sites (look 2 sites and pick)
      * signature handling  (hush->sig etc.)
      * custom mk-origtargz (repack)
      * custom uupdate      (update source tree)

Regards,

Osamu
#874029#37
Date:
2017-12-30 06:12:14 UTC
From:
To:
Package: devscripts
Version: 2.17.11
Followup-For: Bug #874029

I can't tell you how many, but I can tell you that's how Mozilla does it
too, so this applies to firefox, thunderbird, nspr and nss:

https://download-installer.cdn.mozilla.net/pub/firefox/releases/52.5.3esr/SHA256SUMS.asc
https://download-installer.cdn.mozilla.net/pub/thunderbird/releases/52.5.2/SHA512SUMS.asc
https://download-installer.cdn.mozilla.net/pub/nspr/releases/v4.17/src/SHA256SUMS
https://download-installer.cdn.mozilla.net/pub/security/nss/releases/NSS_3_34_1_RTM/src/SHA256SUMS

Note there's actually no signature for nspr and nss (ironically). Which
makes me think checking hashes without signatures could be useful too.
I think I've seen other upstreams with hashes without signatures. Well,
as a matter of fact, there are at least on the gnome ftp:
http://ftp.gnome.org/pub/gnome/sources/glib/2.55/glib-2.55.0.sha256sum

Sure, this is not secure, but security is not the only reason one might
want to check hashes. You can just want to double check you got the
right archive, and not something with some bit flips (although arguably,
that would probably fail to uncompress).

Mike
#874029#42
Date:
2019-03-15 08:46:54 UTC
From:
To:
Control: affects 874029 + src:notmuch

notmuch does it as well:

https://notmuchmail.org/releases/

https://notmuchmail.org/releases/notmuch-0.28.tar.gz.sha256.asc
https://notmuchmail.org/releases/notmuch-0.28.tar.gz


the right way to check it looks something like this (in bash):

           set -o pipefail
           set -x
           wget https://notmuchmail.org/releases/notmuch-0.28.3.tar.gz{,.sha256.asc}
           gpgv --keyring ./notmuch-signers.pgp  --output - notmuch-0.28.3.tar.gz.sha256.asc | sha256sum -c -

The advantage of this approach is that the *name* of the archive is
signed in addition to its contents.

This helps to prevent version fixation or version rollback attacks
(where an attacker simply renames an old tarball and the matching
signature to make it look like it is named the new version.