doc: pass the checksum file explicitly to gpg --verify - #9472
Open
nepet wants to merge 2 commits into
Open
Conversation
We told people to drop SHA256SUMS and SHA256SUMS.asc into the same directory and run `gpg --verify SHA256SUMS.asc`. That relies on gpg guessing what to check, and the guess only happens for a real detached signature. If the .asc turns out to be an inline signed message, gpg verifies the payload embedded in the .asc itself, never touches SHA256SUMS, and exits 0. It does warn on stderr, but that is easy to scroll past and worthless to anything checking the exit code. Spell out both filenames instead, and explain why. Also drop the "gpg: assuming signed data in 'SHA256SUMS'" line from the sample output, since gpg has nothing left to assume once we name the file.
…nature 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.
nepet
added
the
Status::Ready for Review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The reproducible build docs tell you to download the binaries,
SHA256SUMSandSHA256SUMS.ascinto one directory and then runWith a single argument gpg decides what to do based on what's actually inside the
.asc. If it's a detached signature, it guesses the siblingSHA256SUMSand checks it, which is what we want and what our releases produce today. If it's an inline signed message, it verifies the data carried with the.ascitself and never opensSHA256SUMSat all. Both cases exit 0.For a human following the docs, this is mostly covered already. The expected output we print starts with:
That line only appears when gpg made the inference we wanted. Someone comparing their terminal against the docs would notice it missing, and modern gpg additionally prints:
So the manual path has a reasonable chance of catching it. Scripts however have none: both signals are stderr text, older gpg doesn't print the warning at all, and the exit code is 0 either way. Anything checking
$?sees success.Rather than keeping two different standards, use the explicit form everywhere. Naming
SHA256SUMSthe second argument removes the inference entirely: gpg checks the signatures against that file and errors out if.ascisn't a detached signature over it. That also means the "put both files in the same directory" advice is no longer load-bearing, which is good, because it was never making the verification work.Important
26.09 FREEZE August 5th: Non-bugfix PRs not ready by this date will wait for 26.12.
RC1 is scheduled on August 17th
The final release is scheduled for September 7th.
Checklist
Before submitting the PR, ensure the following tasks are completed. If an item is not applicable to your PR, please mark it as checked:
tools/lightning-downgrade