Summary
The release workflow (release.yml:241) generates sha256sums.txt containing per-binary checksums, but the file itself is unsigned. A user who downloads cdidx-1.21.0-linux-x64.tar.gz and sha256sums.txt from the same release page can verify integrity, but if an attacker compromises the GitHub releases CDN (or pulls a successful supply-chain attack on the workflow), they can substitute both the tarball and the checksum file in lockstep. The checksum file needs an out-of-band trust anchor — typically a detached GPG signature signed by a maintainer key whose public part is published outside the same channel.
Where
.github/workflows/release.yml:241 (sha256sums.txt generation step)
Suggested approach
(1) After generating sha256sums.txt, sign it with gpg --armor --detach-sign --local-user <release_key_id> sha256sums.txt, producing sha256sums.txt.asc. (2) Upload sha256sums.txt.asc alongside the manifest in the release. (3) Publish the release public key in the repo (docs/release-key.asc or similar) and on a keyserver, with a note in README.md on how to verify. (4) Update install.sh to verify sha256sums.txt.asc (cross-link the just-filed #1795) before consulting the manifest, and to refuse install if either signature or checksum mismatches. (5) Document the verification procedure for manual users: gpg --verify sha256sums.txt.asc sha256sums.txt. (6) Establish a signing key rotation policy. (7) Cross-link with #1795 (install.sh GPG verify) and the just-filed #461 (Authenticode) — together they form the supply-chain story.
Summary
The release workflow (release.yml:241) generates
sha256sums.txtcontaining per-binary checksums, but the file itself is unsigned. A user who downloadscdidx-1.21.0-linux-x64.tar.gzandsha256sums.txtfrom the same release page can verify integrity, but if an attacker compromises the GitHub releases CDN (or pulls a successful supply-chain attack on the workflow), they can substitute both the tarball and the checksum file in lockstep. The checksum file needs an out-of-band trust anchor — typically a detached GPG signature signed by a maintainer key whose public part is published outside the same channel.Where
.github/workflows/release.yml:241(sha256sums.txt generation step)Suggested approach
(1) After generating
sha256sums.txt, sign it withgpg --armor --detach-sign --local-user <release_key_id> sha256sums.txt, producingsha256sums.txt.asc. (2) Uploadsha256sums.txt.ascalongside the manifest in the release. (3) Publish the release public key in the repo (docs/release-key.ascor similar) and on a keyserver, with a note inREADME.mdon how to verify. (4) Update install.sh to verifysha256sums.txt.asc(cross-link the just-filed #1795) before consulting the manifest, and to refuse install if either signature or checksum mismatches. (5) Document the verification procedure for manual users:gpg --verify sha256sums.txt.asc sha256sums.txt. (6) Establish a signing key rotation policy. (7) Cross-link with #1795 (install.sh GPG verify) and the just-filed #461 (Authenticode) — together they form the supply-chain story.