tools/build-release.sh: name the checksum file when verifying the signature
What the developer wrote
Authored by Peter Neuroth
tools/build-release.sh: name the checksum file when verifying the signature
The --verify path called `gpg --verify ../SHA256SUMS-$VERSION.asc` and
let gpg work out the rest. For a proper detached signature it does find
the sibling file, so this happened to work, but an inline signed .asc
would verify its own embedded payload and exit 0 without ever looking at
the checksums we just compared. Since the exit status is what decides
whether we print "Verified Successfully!", that is not a distinction we
want to leave to gpg.
Changelog-None: docs and release tooling only, nothing user-facing.
What changed, and why it matters
This commit fixes a release-script check that verifies the cryptographic signature on a file of checksums. Previously, the script only told GPG to verify the signature file itself. If someone replaced that signature file with an inline-signed message containing its own text, GPG would still report success without ever checking the actual checksum file. The fix explicitly names the checksum file so GPG verifies the signature against the intended manifest. This is a hardening change in internal release tooling, not a fix for an active vulnerability in the Lightning node software users run.
No immediate user action. Core Lightning maintainers should ensure this change is included in release workflows and consider auditing other GPG verify calls in the repository for the same pattern.
Security signals we found
Incorrect cryptographic verification logic in release tooling
Potential false-positive signature verification with inline-signed .asc substitution
Release-integrity hardening
Evidence from the diff
tools/build-release.sh’s –verify path used gpg --verify ../SHA256SUMS-$VERSION.asc. With a detached signature GPG infers the signed data from the sibling filename, but with an inline-signed (cleartext/clear-signed) .asc GPG verifies only the embedded payload and exits 0 without reading SHA256SUMS-$VERSION. The patch changes the invocation to gpg --verify ../SHA256SUMS-$VERSION.asc ../SHA256SUMS-$VERSION, forcing verification of the explicit manifest. This prevents a substitution of the .asc file from producing a false ‘Verified Successfully!’ result after the local checksum comparison has already passed.
Changed components
tools/build-release.shInspect captured patch +5 / −2
### tools/build-release.sh
@@ -276,8 +276,11 @@ if [ "$VERIFY_RELEASE" = "true" ]; then
echo "Error: SHA256SUMS do NOT Match"
exit 1
fi
- # verify release captain signature
- gpg --verify "../SHA256SUMS-$VERSION.asc"
+ # Verify release captain signature. Pass the manifest explicitly: with only
+ # the .asc argument gpg picks its mode from the file's packet structure and
+ # would verify a payload embedded in an inline-signed .asc, exiting 0
+ # without ever reading the checksums we just compared.
+ gpg --verify "../SHA256SUMS-$VERSION.asc" "../SHA256SUMS-$VERSION"
# create ASCII-armored detached signature
gpg -sb --armor < SHA256SUMS > SHA256SUMS.new
echo "Verified Successfully! Signature Updated in release/SHA256SUMS.new"Why this scored 25/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.