Description
contrib/install.sh currently downloads a checksum file from the same GitHub release as the binary and verifies the binary against it:
|
http_download "${tmpdir}/${TARBALL}" "${TARBALL_URL}" |
|
http_download "${tmpdir}/${CHECKSUM}" "${CHECKSUM_URL}" |
|
hash_sha256_verify "${tmpdir}/${TARBALL}" "${tmpdir}/${CHECKSUM}" |
Since both the binary and the checksum file come from the same release assets, this verification is effectively a download-integrity check (it catches network corruption or partial downloads), not a security check against tampering. If an attacker can modify the release assets, they can modify the checksum file too.
This issue proposes adding a way for users to supply an expected checksum to install.sh themselves, so that the script verifies the downloaded binary against a value the user already trusts (e.g. one pinned in their CI configuration or fetched out-of-band).
Caveat
contrib/install.sh itself lives in this repository, so a repository compromise could also modify the script to bypass the user-supplied checksum. To get real benefit from this feature, users should pin install.sh to a known-good commit and supply the expected checksum from a trusted location.
This is exactly the model already used by aquasecurity/setup-trivy, which checks out contrib/install.sh at a pinned commit SHA before running it. Adding a checksum option to install.sh would let setup-trivy (and trivy-action) forward a user-supplied checksum end-to-end.
Proposed interface (to be discussed)
The current script already accepts both flags and matching environment variables (-b / BINDIR, -c / CLIENT). The same pattern can be extended:
# Flag form
./install.sh -b /usr/local/bin -k <sha256-of-asset> v0.69.2
# Env-var form (mirrors existing BINDIR / CLIENT convention)
TRIVY_CHECKSUM=<sha256> ./install.sh -b /usr/local/bin v0.69.2
Exact flag letter and env-var name are open for discussion.
Follow-up
Once supported in install.sh, the same option should be exposed through:
so that users can pin both the action commit SHA and the expected Trivy binary checksum.
Related
Target
None
Scanner
None
Description
contrib/install.shcurrently downloads a checksum file from the same GitHub release as the binary and verifies the binary against it:trivy/contrib/install.sh
Lines 59 to 61 in 99eabdf
Since both the binary and the checksum file come from the same release assets, this verification is effectively a download-integrity check (it catches network corruption or partial downloads), not a security check against tampering. If an attacker can modify the release assets, they can modify the checksum file too.
This issue proposes adding a way for users to supply an expected checksum to
install.shthemselves, so that the script verifies the downloaded binary against a value the user already trusts (e.g. one pinned in their CI configuration or fetched out-of-band).Caveat
contrib/install.shitself lives in this repository, so a repository compromise could also modify the script to bypass the user-supplied checksum. To get real benefit from this feature, users should pininstall.shto a known-good commit and supply the expected checksum from a trusted location.This is exactly the model already used by
aquasecurity/setup-trivy, which checks outcontrib/install.shat a pinned commit SHA before running it. Adding a checksum option toinstall.shwould letsetup-trivy(andtrivy-action) forward a user-supplied checksum end-to-end.Proposed interface (to be discussed)
The current script already accepts both flags and matching environment variables (
-b/BINDIR,-c/CLIENT). The same pattern can be extended:Exact flag letter and env-var name are open for discussion.
Follow-up
Once supported in
install.sh, the same option should be exposed through:so that users can pin both the action commit SHA and the expected Trivy binary checksum.
Related
cosign-based verification option, which is not covered by this issue and should be tracked separatelyTarget
None
Scanner
None