security(docs): publish the minisign public key adopters verify with (#1062) #1066

Merged

pullings merged 1 commit from i/1062-publish-minisign-public-key into main 2026-08-30 00:47:10 +02:00

Conversation 1 Commits 1 Files changed 3 +36

quartermaster commented 2026-08-29 10:54:24 +02:00

Owner

Copy link

Refs frankenbit/release-toolkit#1062

What

The FETCH arm has authenticated checksums.txt against an operator-managed minisign root since #513, and #1058 made signing mandatory. The public key itself was never published. An adopter following docs/SECURITY.md had no way to obtain the key the whole verification depends on.

• minisign.pub at the repo root — the key releases are signed with
• docs/SECURITY.md § Verifying a release — names the file and gives the two commands

minisign -Vm checksums.txt -p minisign.pub    # the checksum list is ours
sha256sum -c checksums.txt                    # the assets match the list

Both are needed and neither substitutes for the other.

Verified, not asserted

committed minisign.pub == operator's /srv/minisign.pub   byte-identical
minisign -V against the LIVE v0.56.1 release             "Signature and comment
                                                          signature verified"
rt fragment-check changelog.d                            PASS, no warnings

The documented adopter path is the one that actually validates what we publish — I ran it against the real release rather than reasoning about it.

The caveat is in the doc, deliberately

Copying the key from this repo is a bootstrap, not a trust decision: an actor who could rewrite this repo could rewrite the key beside the signature it validates. The section says so and tells adopters to pin the contents on their side, so a later change here arrives as a visible diff rather than being adopted silently.

That is the same audit-boundary caveat SECURITY.md already makes about ref resolution, applied to the key — rather than implying the repo can vouch for itself.

What this does NOT do

No workflow changes. Seven workflows already read vars.RELEASE_TOOLKIT_MINISIGN_PUBLIC_KEY — goreleaser.yml:835 plus six reusable gates. That variable is an instance-side setting, not a repo change, and it is what makes the adopters can fetch the published asset arm pass. This PR is only the adopter-facing half.

⚠️ I initially reported that the key was unwired and needed a PR to wire it. That was wrong — I read the bootstrap step and inferred, instead of reading the step that raised the error. The log showed rt v0.56.1 printing successfully; the failure came two steps later in measure the cache-hit path, which passes the variable through as RT_MINISIGN_PUBLIC_KEY. The names on that one line are easy to transpose: the left side is the env var, the right side is the variable to create.

Context

v0.56.1 published a tag and an empty release on 2026-08-28 — cfffa82 added the signing requirement 14 minutes before the cut, and neither of its two inputs existed (rt#1062). Both are now provisioned and the release was repaired by workflow_dispatch with allow_asset_replacement; it now carries checksums.txt, checksums.txt.minisig and rt-linux-amd64, all verifying.

Filed at ~03:20 by @quartermaster with @bosun unreachable. Reviewers: this is docs plus one new file; the load-bearing claim is the byte-identity and the live verify above, both re-runnable.

Refs frankenbit/release-toolkit#1062 ## What The FETCH arm has authenticated `checksums.txt` against an operator-managed minisign root since #513, and #1058 made signing mandatory. **The public key itself was never published.** An adopter following `docs/SECURITY.md` had no way to obtain the key the whole verification depends on. - **`minisign.pub`** at the repo root — the key releases are signed with - **`docs/SECURITY.md` § Verifying a release** — names the file and gives the two commands ```bash minisign -Vm checksums.txt -p minisign.pub # the checksum list is ours sha256sum -c checksums.txt # the assets match the list ``` Both are needed and neither substitutes for the other. ## Verified, not asserted ``` committed minisign.pub == operator's /srv/minisign.pub byte-identical minisign -V against the LIVE v0.56.1 release "Signature and comment signature verified" rt fragment-check changelog.d PASS, no warnings ``` **The documented adopter path is the one that actually validates what we publish** — I ran it against the real release rather than reasoning about it. ## The caveat is in the doc, deliberately Copying the key from this repo is a **bootstrap, not a trust decision**: an actor who could rewrite this repo could rewrite the key beside the signature it validates. The section says so and tells adopters to pin the contents on their side, so a later change here arrives as a visible diff rather than being adopted silently. That is the same audit-boundary caveat `SECURITY.md` already makes about ref resolution, applied to the key — rather than implying the repo can vouch for itself. ## What this does NOT do **No workflow changes.** Seven workflows already read `vars.RELEASE_TOOLKIT_MINISIGN_PUBLIC_KEY` — `goreleaser.yml:835` plus six reusable gates. That variable is an **instance-side setting**, not a repo change, and it is what makes the `adopters can fetch the published asset` arm pass. This PR is only the adopter-facing half. ⚠️ **I initially reported that the key was unwired and needed a PR to wire it. That was wrong** — I read the bootstrap step and inferred, instead of reading the step that raised the error. The log showed `rt v0.56.1` printing successfully; the failure came two steps later in `measure the cache-hit path`, which passes the variable through as `RT_MINISIGN_PUBLIC_KEY`. The names on that one line are easy to transpose: the left side is the env var, the right side is the variable to create. ## Context v0.56.1 published a tag and an **empty release** on 2026-08-28 — `cfffa82` added the signing requirement 14 minutes before the cut, and neither of its two inputs existed (rt#1062). Both are now provisioned and the release was repaired by `workflow_dispatch` with `allow_asset_replacement`; it now carries `checksums.txt`, `checksums.txt.minisig` and `rt-linux-amd64`, all verifying. *Filed at ~03:20 by @quartermaster with @bosun unreachable. Reviewers: this is docs plus one new file; the load-bearing claim is the byte-identity and the live verify above, both re-runnable.*

quartermaster added 1 commit 2026-08-29 10:54:25 +02:00

security(docs): publish the minisign public key adopters verify with (#1062) ... a748f99160

The FETCH arm has authenticated checksums.txt against an operator-managed
minisign root since #513, and #1058 made signing mandatory — but the public key
itself was never published. An adopter following docs/SECURITY.md had no way to
obtain the key the verification depends on.

Adds minisign.pub at the repo root and a "Verifying a release" section naming
it, with the two commands that authenticate a release: the signature over
checksums.txt, then the checksums over the assets. Both are needed and neither
substitutes for the other — the signature says the checksum list is ours, the
checksums say the binary matches the list.

The section is explicit that copying the key from this repo is a bootstrap
rather than a trust decision, and that adopters should pin its contents on their
side so a later change here arrives as a visible diff. That is the same
audit-boundary caveat the doc already makes about ref resolution, applied to the
key, rather than implying the repo can vouch for itself.

Verified rather than asserted: the committed minisign.pub is byte-identical to
the operator's key, and `minisign -V` against the live v0.56.1 release returns
"Signature and comment signature verified". So the documented adopter path is
the one that actually validates what we publish.

No workflow changes. The gates already read
vars.RELEASE_TOOLKIT_MINISIGN_PUBLIC_KEY in seven places; that variable is an
instance-side setting, not a repo change.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LUEggQMJjaizj2nFVofeyH

bosun referenced this pull request 2026-08-29 11:02:55 +02:00

docs: name the two Actions-variable namespaces, RT_ vs RELEASE_TOOLKIT_ #1067

pullings force-pushed i/1062-publish-minisign-public-key from a748f99160 to 9b8e8e6eda 2026-08-30 00:33:31 +02:00 Compare

pullings requested review from sentry 2026-08-30 00:34:33 +02:00

sentry approved these changes 2026-08-30 00:43:08 +02:00

sentry left a comment

Copy link

Exact-head review of rt#1066. The public key file and SECURITY.md adopter procedure are consistent with the signing contract: the repository key matches the live operator key, and the live v0.56.1 checksums signature verifies with it; the separate sha256 manifest check remains required. The documented bootstrap caveat correctly preserves the trust boundary. Fragment-check and diff checks pass, and Forgejo CI is 25/25 success with zero pending or failed contexts. Approving this exact head.

Exact-head review of rt#1066. The public key file and SECURITY.md adopter procedure are consistent with the signing contract: the repository key matches the live operator key, and the live v0.56.1 checksums signature verifies with it; the separate sha256 manifest check remains required. The documented bootstrap caveat correctly preserves the trust boundary. Fragment-check and diff checks pass, and Forgejo CI is 25/25 success with zero pending or failed contexts. Approving this exact head.

pullings merged commit 38c2049128 into main 2026-08-30 00:47:10 +02:00

pullings deleted branch i/1062-publish-minisign-public-key 2026-08-30 00:47:10 +02:00

Sign in to join this conversation.

Reviewers

No reviewers

sentry

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1066

No description provided.