kumquat-buildroot/support/download/check-hash

116 lines
3.4 KiB
Plaintext
Raw Normal View History

#!/usr/bin/env bash
set -e
# Helper to check a file matches its known hash
# Call it with:
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
# $1: the full path to the temporary file that was downloaded, and
# that is to be checked
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
# $2: the final basename of the file, to which it will be ultimately
# saved as, to be able to match it to the corresponding hashes
# in the .hash file
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
# $*: the paths of the files containing all the expected hashes
#
# Exit codes:
# 0: the hash file exists and the file to check matches all its hashes,
# or the hash file does not exist
# 1: unknown command-line option
# 2: the hash file exists and the file to check does not match at least
# one of its hashes
# 3: the hash file exists and there was no hash to check the file against
# 4: the hash file exists and at least one hash type is unknown
while getopts :q OPT; do
case "${OPT}" in
q) exec >/dev/null;;
\?) exit 1;;
esac
done
shift $((OPTIND-1))
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
file="${1}"
base="${2}"
shift 2
declare -a h_files=( "${@}" )
# Check one hash for a file
# $1: algo hash
# $2: known hash
# $3: file (full path)
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
# $4: hash file (full path)
check_one_hash() {
_h="${1}"
_known="${2}"
_file="${3}"
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
_h_file="${4}"
# Note: md5 is supported, but undocumented on purpose.
# Note: sha3 is not supported, since there is currently no implementation
# (the NIST has yet to publish the parameters).
case "${_h}" in
md5|sha1) ;;
sha224|sha256|sha384|sha512) ;;
*) # Unknown hash, exit with error
printf "ERROR: unknown hash '%s' for '%s'\n" \
"${_h}" "${base}" >&2
exit 4
;;
esac
# Do the hashes match?
_hash="$( "${_h}sum" "${_file}" |cut -d ' ' -f 1 )"
if [ "${_hash}" = "${_known}" ]; then
printf "%s: OK (%s: %s)\n" "${base}" "${_h}" "${_hash}"
return 0
fi
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
printf "ERROR: while checking hashes from %s\n" "${_h_file}" >&2
printf "ERROR: %s has wrong %s hash:\n" "${base}" "${_h}" >&2
printf "ERROR: expected: %s\n" "${_known}" >&2
printf "ERROR: got : %s\n" "${_hash}" >&2
printf "ERROR: Incomplete download, or man-in-the-middle (MITM) attack\n" >&2
exit 2
}
# Do we know one or more hashes for that file?
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
nb_h_files=0
nb_checks=0
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
for h_file in "${h_files[@]}"; do
[ -f "${h_file}" ] || continue
: $((nb_h_files++))
# shellcheck disable=SC2094 # we're really reading it only once
while read -r t h f; do
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
case "${t}" in
''|'#'*)
# Skip comments and empty lines
continue
;;
*)
if [ "${f}" = "${base}" ]; then
# shellcheck disable=SC2094 # we're only printing the h_file filename
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
check_one_hash "${t}" "${h}" "${file}" "${h_file}"
: $((nb_checks++))
fi
;;
esac
done <"${h_file}"
done
# shellcheck disable=SC2086 # nb_h_files is a non-empty int
support/download: teach dl-wrapper to handle more than one hash file Currently, we expect and only use hash files that lie within the package directory, alongside the .mk file. Those hash files are thus bundled with Buildroot. This implies that only what's known to Buildroot can ever get into those hash files. For packages where the version is fixed (or a static choice), then we can carry hashes for those known versions. However, we do have a few packages for which the version is a free-form entry, where the user can provide a custom location and/or version. like a custom VCS tree and revision, or a custom tarball URL. This means that Buildroot has no way to be able to cary hashes for such custom versions. This means that there is no integrity check that what was downloaded is what was expected. For a sha1 in a git tree, this is a minor issue, because the sha1 by itself is already a hash of the expected content. But for custom tarballs URLs, or for a tag in a VCS, there is indeed no integrity check. Buildroot can't provide such hashes, but interested users may want to provide those, and currently there is no (easy) way to do so. So, we need our download helpers to be able to accept more than one hash file to lookup for hashes. Extend the dl-wrapper and the check-hash helpers thusly, and update the legal-info accordingly. Note that, to be able to pass more than one hash file, we also need to re-order the arguments passed to support/download/check-hash, which also impies some shuffling in the three places it is called: - 2 in dl-wrapper - 1 in the legal-info infra That in turn also requires that the legal-license-file macro args get re-ordered to have the hash file last; we take the opportunity to also move the HOST/TARGET arg to be first, like in the other legal-info macros. Reported-by: "Martin Zeiser (mzeiser)" <mzeiser@cisco.com> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2023-11-06 20:09:12 +01:00
if [ ${nb_h_files} -eq 0 ]; then
printf "WARNING: no hash file for %s\n" "${base}" >&2
exit 0
fi
# shellcheck disable=SC2086 # nb_checks is a non-empty int
if [ ${nb_checks} -eq 0 ]; then
support/download: add possibility to not fail on missing hash In very constrained cases, it might be needed to not fail if a hash is missing. This is notably the case for custom external toolchains to be downloaded, because we do have a .hash file for external toolchains, but we obviously can not have hashes for all existing custom toolchains (he, "custom"!). So, add a way to avoid failing in that case. >From the Makefile, we export the list of files for which not to check the hash. Then, from the check-hash script, if no check was done, and the file we were trying to match in in this exclusion list, we just exit without error. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> changes v6 -> v7: - /beautify/ the pattern in the case clause Changed v5 -> v6: (Arnout) - fix the pattern in the case clause Changes v4 -> v5: - micro-optimisation, use case-esac instead of a for-loop (Arnout) - typoes (Arnout) Changes v3 -> v4: - drop the magic value, use a list of excluded files (Arnout) Changes v1 -> v2: - fix typoes in commit log Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2015-04-23 00:08:38 +02:00
case " ${BR_NO_CHECK_HASH_FOR} " in
*" ${base} "*)
# File explicitly has no hash
exit 0
;;
esac
printf "ERROR: No hash found for %s\n" "${base}" >&2
exit 3
fi