doc: pass the checksum file explicitly to gpg --verify

doc/contribute-to-core-lightning/release-checklist.md

@@ -82,7 +82,7 @@ Here's a checklist for the release process.
    - Run `tools/build-release.sh --verify`. It will create reproducible images, verify checksums and sign.
    - Send your signatures from `release/SHA256SUMS-v<VERSION>.asc` to release captain.
    - Or follow [link](https://docs.corelightning.org/docs/repro#verifying-a-reproducible-build) for manual verification instructions.
-12. Append signatures shared by the team into the `SHA256SUMS-v<VERSION>.asc` file, verify with `gpg --verify SHA256SUMS-v<VERSION>.asc` and include the file in the draft release.
+12. Append signatures shared by the team into the `SHA256SUMS-v<VERSION>.asc` file, verify with `gpg --verify SHA256SUMS-v<VERSION>.asc SHA256SUMS-v<VERSION>` (always pass the manifest as the second argument, otherwise `gpg` may verify a payload embedded in the `.asc` and exit successfully without ever reading the checksums) and include the file in the draft release.
 13. The GitHub action `Publish Python 🐍 distributions 📦 to PyPI and TestPyPI` should upload the pyln modules to pypi.org. However, this can also be done manually by running `uv run make pyln-release`. This process requires keys for each of the `pyln-client`, `pyln-proto`, and `pyln-testing` modules to be accessible to uv. You can set the key as an environment variable and build and publish each pyln release independently:
     - `export UV_PUBLISH_TOKEN=<pyln-client token>`
     - `uv run make pyln-release-client`
@@ -124,7 +124,7 @@ Here's a checklist for the release process.
 10. Sign the release locally by running `tools/build-release.sh bin-Fedora bin-Ubuntu sign` which will sign the release contents and create `SHA256SUMS-v<VERSION>` and `SHA256SUMS-v<VERSION>.asc` in the release folder.
 11. Validate that your local checksums `SHA256SUMS-v<VERSION>` match the Draft release's, then add your signatures to the draft release's signature `SHA256SUMS-v<VERSION>.asc` file.
 12. Share the `SHA256SUMS-v<VERSION>` and `SHA256SUMS-v<VERSION>.asc` files with the team for verification and signing.
-13. Append the signatures received from the team to the `SHA256SUMS-v<VERSION>.asc` file. Verify the file using `gpg --verify SHA256SUMS-v<VERSION>.asc`. Then re-upload the file.
+13. Append the signatures received from the team to the `SHA256SUMS-v<VERSION>.asc` file. Verify the file using `gpg --verify SHA256SUMS-v<VERSION>.asc SHA256SUMS-v<VERSION>`; the manifest must be passed as the second argument, otherwise `gpg` may verify a payload embedded in the `.asc` and exit successfully without ever reading the checksums. Then re-upload the file.
 14. Finalize and publish the release (change it from draft to public).
 15. Ensure that the GitHub Actions for `Publish Python 🐍 distributions 📦 to PyPI and TestPyPI` and `Build and push multi-platform docker images` are functioning correctly. Check that the `PyPI` modules published on `https://pypi.org/project/pyln-*` and that the Docker image has been uploaded to Docker Hub.
 16. Create a PR to merge updates from `update-versions` and `CHANGELOG.md` into `master` to keep it up-to-date for the next release.

doc/getting-started/advanced-setup/repro.md

@@ -148,11 +148,13 @@ gpg -sb --armor SHA256SUMS
 4. Then send the resulting `release/SHA256SUMS.asc` file to the release captain so it can be merged with the other signatures into `SHASUMS.asc`.
 
 ## Manual
-Co-maintainers and contributors wishing to add their own signature verify that the `SHA256SUMS` and `SHA256SUMS.asc` files created by the release captain matches their binaries before also signing the manifest:
+Co-maintainers and contributors wishing to add their own signature verify that the `SHA256SUMS` and `SHA256SUMS.asc` files created by the release captain matches their binaries before also signing the manifest.
+
+Always pass **both** files to `gpg --verify`: the signature first, then the file it is supposed to cover. See [Verifying a reproducible build](#verifying-a-reproducible-build) below for why the single-argument form is not sufficient.
 
 ```shell
 cd release/
-gpg --verify SHA256SUMS.asc
+gpg --verify SHA256SUMS.asc SHA256SUMS
 sha256sum -c SHA256SUMS
 cat SHA256SUMS | gpg -sb --armor > SHA256SUMS.new
 ```
@@ -169,13 +171,14 @@ You can verify the reproducible build in two ways:
 Assuming you have downloaded the binaries, the manifest and the signatures into the same directory, you can verify the signatures with the following:
 
 ```shell
-gpg --verify SHA256SUMS.asc
+gpg --verify SHA256SUMS.asc SHA256SUMS
 ```
 
+Pass both filenames explicitly. With a single argument `gpg` picks its verification mode from the packet structure of the `.asc` file: for a genuine detached signature it guesses the sibling `SHA256SUMS`, but for an inline (clear-signed or embedded) message it verifies only the payload carried inside the `.asc` itself. It never reads `SHA256SUMS` in that case, and although it prints `WARNING: not a detached signature; file 'SHA256SUMS' was NOT verified!`, it still exits with status 0 — so the warning is easy to miss by eye and invisible to any script that only checks the exit code. Naming the manifest as the second argument forces `gpg` to check the signatures against that exact file, and to fail outright if the `.asc` is not a detached signature over it.
+
 And you should see a list of messages like the following:
 
 ```shell
-gpg: assuming signed data in 'SHA256SUMS'
 gpg: Signature made Fr 08 Mai 2020 07:46:38 CEST
 gpg:                using RSA key 15EE8D6CAB0E7F0CF999BFCBD9200E6CD1ADB8F1
 gpg: Good signature from "Rusty Russell <rusty@rustcorp.com.au>" [full]

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"