ci: require signer OTS proof for final releases

[ziggie1984]

Change Description

Require final published releases to include OpenTimestamps proof artifacts for:

• the release manifest: manifest-${VERSION}.txt.ots
• at least
  one trusted developer signature: manifest-<signer>-${VERSION}.sig.ots

Release candidate tags ending in .rcN are skipped.

The signature OTS check is constrained to trusted
release signers from scripts/verify-install.sh, and only passes when the matching uploaded manifest-<signer>-${VERSION}.sig asset is also present.

This also fixes the generated
release text to document the actual OTS artifact names and verification commands.

Steps to Test

• Parsed .github/workflows/release.yaml and .github/workflows/verify- release.yaml locally with Ruby YAML loading.
• Tested the final/RC tag matching logic locally.
• Tested trusted signer matching against scripts/verify-install.sh.
• Ran git diff --check.

[gemini-code-assist]

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

[github-actions]

🟢 PR Severity: LOW

Automated classification | 1 file | 40 lines changed

🟢 Low (1 file)

• .github/workflows/verify-release.yaml - CI/CD workflow configuration file

Analysis

This PR modifies a single GitHub Actions workflow file (.github/workflows/verify-release.yaml). Files under .github/* are classified as LOW severity as they represent CI'D configuration changes with no impact on the Lightning Network daemon's core logic, security model, or financial operations.

No severity bump was applied: only 1 non-test, non-generated file changed (threshold: >20), and only 40 lines were modified (threshold: >500).

---

_{To override, add a severity-override-{critical,high,medium,low} label.}
<!-- pr-severity-bot -->

[Copilot]

Pull request overview

This PR tightens the release verification pipeline by requiring OpenTimestamps (OTS) proof artifacts to be present on final GitHub releases, ensuring the release manifest and at least one trusted developer signature have corresponding .ots proofs. It also updates the release body text to document the correct OTS artifact names and verification commands.

Changes:

• Add a pre-check in the verify-release workflow to enforce presence of manifest-${VERSION}.txt.ots and at least one manifest-<trusted-signer>-${VERSION}.sig.ots (and its matching .sig) for non-.rcN tags.
• Constrain acceptable signer OTS proofs to the trusted signer list derived from scripts/verify-install.sh.
• Update the generated release text to reflect the actual OTS artifact filenames and ots verify commands.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
.github/workflows/verify-release.yaml	Adds a final-release-only OTS asset enforcement step (with trusted signer matching) before running the existing Docker-based verification.
.github/workflows/release.yaml	Fixes the release notes template to document the correct OTS proof artifact names and verification commands.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[saubyk]

Process note: this step runs on release: published, so if maintainers publish the release before uploading the .sig.ots/.txt.ots assets, the gate fails and the existing if: failure() handler reverts the release to draft. It's recoverable (upload assets, re-publish), but it's a behavioral change worth calling out in the release runbook — the first release after this merges is the most likely to trip on it.

[saubyk]

For workflow_dispatch with an older version input, actions/checkout@v4 checks out the default branch, so TRUSTED_SIGNERS is read from current master rather than the released tag's verify-install.sh. Harmless while the signer list only grows, but if a signer is ever removed a historical re-verify could behave inconsistently. Consider pinning ref: ${{ inputs.version || github.sha }}.

[saubyk]

This sed is tightly coupled to the exact KEYS+=("<fp> <name>") line shape in verify-install.sh. If that format ever changes, TRUSTED_SIGNERS silently becomes empty and every final release fails with the generic "missing OTS proof" error. A defensive guard would turn that into a clear failure:

[[ -n "${TRUSTED_SIGNERS}" ]] || { echo "ERROR: no trusted signers parsed from verify-install.sh"; exit 1; }

(FWIW I verified the current regex extracts all 14 signers correctly and handles hyphenated names like ViktorT-11.)

[saubyk]

Worth being explicit that this gate verifies the presence of the .ots asset names — it never runs ots verify on them, so a malformed/empty proof file would still pass. The trusted-signer + matching-.sig constraints make presence a reasonable bar, but the PR title ("require signer OTS proof") slightly oversells it: it requires the proof file, not a valid proof. Either tweak the wording or consider actually validating the timestamp if integrity is the goal.

[saubyk]

Nit (pre-existing wording carried into this edited line): "in addition time-stamping the git tag" reads as missing a "to" — "in addition to time-stamping the git tag". Easy to fix while this line is already being rewritten.

[saubyk]

Non blocking comments