chore(release): publish only to GitHub Releases, and harden the signer

[barbatos2011]

The release pipeline advertised four channels: GitHub Releases, a Homebrew tap, .deb/.rpm/.apk packages, and a Docker Hub image. Two of them cost a long-lived credential, and neither of those two could be covered by the signature we tell users to verify. This drops them and keeps GitHub Releases as the only channel.

Why the two channels go

tronprotocol/homebrew-tap does not exist, and the brews: block carried no token: — so it would have run on the default GITHUB_TOKEN, which cannot write to another repository. Making it work needed a cross-repo PAT. tronprotocol/trond on Docker Hub does not exist either (404) and needed a DOCKERHUB_TOKEN.

Both are secrets that sit in this repository's Actions settings until someone rotates them, and whoever holds one can publish a trond that users trust, under the official name. The cosign signing here is keyless precisely to avoid that — its credential is an OIDC token minted for a single workflow run.

They were also outside what the signature can reach. signs: covers checksums.txt, and checksums.txt lists the file artifacts goreleaser built. A tap formula is pushed to another repository; an image is pushed to a registry by digest. Neither appears in it.

README nonetheless said the signature "transitively covers every artifact (tarballs, .deb / .rpm / .apk packages, docker images, the homebrew formula)". A local snapshot build shows checksums.txt holding 14 entries — archives and packages, no formula:

$ goreleaser release --snapshot --clean --skip=publish,sign
$ wc -l < dist/checksums.txt
14
$ ls dist/homebrew
(no such directory)

That sentence is corrected, and the reason the channels are gone is recorded in .goreleaser.yaml and in the constitution so it is not re-added by accident.

Two more findings, same blast radius

Both surfaced from actually running the pipeline rather than reading it.

The before: hook ran go mod tidy. tidy writes to go.mod/go.sum, so a release need not be built from the reviewed, committed lockfile. This is not theoretical — a local snapshot run left go.sum modified in the worktree (it pruned a stale golang.org/x/net v0.54.0). Now go mod download + go mod verify, which only read.

release.yml referenced its actions by moving tag and pulled goreleaser at version: latest. That job holds contents: write and id-token: write — it can publish and sign, so everything it runs is in the trusted computing base of every signature this project issues, and a tag repointed upstream would be an unreviewed change to the signer. Actions are now pinned to commit SHAs at their current versions (no major bumps), goreleaser to ~> v2.17.

Incidental fixes

• archives.builds → archives.ids, and the brews deprecation is gone with the block — goreleaser check passes for the first time (it previously exited non-zero, and is not run in CI).
• The snapshot smoke asserted dist/homebrew/*.rb, which would now never appear. Removed, along with the dead --skip=docker.
• CHANGELOG.md had ## [0.1.0-alpha] — 2026-XX-XX twice in a row.
• install.sh printed "could not query the latest release" for what is really prerelease: auto: /releases/latest omits pre-releases, so an alpha-only tag 404s there and the message blamed the network. It now names the real cause. Installing a pre-release stays opt-in via TROND_VERSION.
• Dockerfile.release deleted — its only consumer was the removed dockers_v2 block.

Verification

check	result
goreleaser check	clean (was failing)
goreleaser release --snapshot	all 14 artifacts, exit 0
go.mod / go.sum after that build	untouched
snapshot workflow's assertion, re-run under bash	passes
make test	25 packages ok, 0 failures
Go files touched	none

Still open — not in this PR

• The tag trigger stays disabled pending TX-167; that reference appears nowhere else in the repo, so someone who knows what it was needs to decide whether it still applies.
• The first version number is unpicked. If it carries a pre-release suffix, prerelease: auto files it as a pre-release and the README one-liner will not resolve it.
• The other seven workflows still reference actions by tag. Lower privilege than release.yml, but the same class of issue.
• Neither the cosign signing step nor a real publish has ever executed — the snapshot smoke skips both. Worth one workflow_dispatch run on a throwaway tag before the first real release.

Reintroducing a tap or an image later is a real option, not a prohibition. It needs a named credential-rotation owner and a verification story of its own — a fine-grained PAT scoped to contents:write on the tap alone, and cosign sign on the image digest (or GHCR plus build provenance, which needs no standing secret at all).