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
• Copy Markdown

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.*

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
• Copy Markdown

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

epic

Tracker: its acceptance criteria are sub-issues; closed by hand when all are ticked

  

kind

feature

New feature or capability

  

loop/paused

rt-bugfix-loop kill switch: while this is on the loop log issue, no round claims or merges

  

mirror-drift

Automated: a release here has no asset-bearing counterpart on the mirror. One tracker per drift episode; the check never reopens a closed one (#1586)

  

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+

  

status

blocked

Cannot start until a named dependency resolves

No labels

bump

major

bump

minor

bump

patch

kind

bug

kind

chore

kind

docs

kind

epic

kind

feature

loop/paused

mirror-drift

priority

critical

priority

high

priority

low

priority

medium

size

L

size

M

size

S

size

XL

status

blocked

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.