aboutsummaryrefslogtreecommitdiffstats
path: root/tools/expat/Makefile
diff options
context:
space:
mode:
authorBaptiste Jonglez <git@bitsofnetworks.org>2017-09-03 14:01:28 +0200
committerJohn Crispin <john@phrozen.org>2017-09-11 17:13:02 +0200
commitb30ba14e2a858cfebcfdbc38348ab96a6d179556 (patch)
tree120211c972aac36d399e47ab2aaa4cc0ead8ee33 /tools/expat/Makefile
parent13e5e473699b92f171205e0f5c57c9ebe7922492 (diff)
downloadupstream-b30ba14e2a858cfebcfdbc38348ab96a6d179556.tar.gz
upstream-b30ba14e2a858cfebcfdbc38348ab96a6d179556.tar.bz2
upstream-b30ba14e2a858cfebcfdbc38348ab96a6d179556.zip
scripts/download.pl: 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/download.pl 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 download.pl instead of relying on the hash being empty. Fixes: eaa4eba10a89 ("scripts/download.pl: add SHA-256 support") Signed-off-by: Baptiste Jonglez <git@bitsofnetworks.org>
Diffstat (limited to 'tools/expat/Makefile')
0 files changed, 0 insertions, 0 deletions