Browse files

scripts/ fail loudly if provided hash is unsupported

Currently, if the provided hash is unsupported (length different from 32
or 64 bytes), we happily download the requested file without any kind of
checksum verification.

This is quite dangerous and may provide a false sense of security, because
a single typo in the hash (e.g. one character deleted by mistake) may skip
checksum verification entirely.

Instead, fail immediately if we don't support the provided hash.
In particular, if an external package repository decides to change the
hash algorithm one day, we will now fail loudly instead of skipping
checksum verification without complaints.

Note: if some users of scripts/ knowingly provide an empty hash
because they don't need checksum verification, this change will break
them.  This does not seem to be the case currently, but if this feature is
ever needed, an option should be added to instead of relying
on the hash being empty.

Fixes: eaa4eba ("scripts/ add SHA-256 support")

Signed-off-by: Baptiste Jonglez <>
  • Loading branch information...
Baptiste Jonglez authored and blogic committed Sep 3, 2017
1 parent 13e5e47 commit b30ba14e2a858cfebcfdbc38348ab96a6d179556
Showing with 1 addition and 0 deletions.
  1. +1 −0 scripts/
@@ -88,6 +88,7 @@ ($)

my $hash_cmd = hash_cmd();
$hash_cmd or die "Cannot find appropriate hash command, ensure the provided hash is either a MD5 or SHA256 checksum.\n";

sub download

0 comments on commit b30ba14

Please sign in to comment.