diff --git a/doc/contribute-to-core-lightning/release-checklist.md b/doc/contribute-to-core-lightning/release-checklist.md index a3222c13bfd1..50215b3e4481 100644 --- a/doc/contribute-to-core-lightning/release-checklist.md +++ b/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.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.asc` file, verify with `gpg --verify SHA256SUMS-v.asc` and include the file in the draft release. +12. Append signatures shared by the team into the `SHA256SUMS-v.asc` file, verify with `gpg --verify SHA256SUMS-v.asc SHA256SUMS-v` (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=` - `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` and `SHA256SUMS-v.asc` in the release folder. 11. Validate that your local checksums `SHA256SUMS-v` match the Draft release's, then add your signatures to the draft release's signature `SHA256SUMS-v.asc` file. 12. Share the `SHA256SUMS-v` and `SHA256SUMS-v.asc` files with the team for verification and signing. -13. Append the signatures received from the team to the `SHA256SUMS-v.asc` file. Verify the file using `gpg --verify SHA256SUMS-v.asc`. Then re-upload the file. +13. Append the signatures received from the team to the `SHA256SUMS-v.asc` file. Verify the file using `gpg --verify SHA256SUMS-v.asc SHA256SUMS-v`; 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. diff --git a/doc/getting-started/advanced-setup/repro.md b/doc/getting-started/advanced-setup/repro.md index 78b79faae010..e913ef72649c 100644 --- a/doc/getting-started/advanced-setup/repro.md +++ b/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 " [full] diff --git a/tools/build-release.sh b/tools/build-release.sh index fcdc8dce9f82..5d18c8105c49 100755 --- a/tools/build-release.sh +++ b/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"