.github/workflows/upstream-release-docs.yml runs scripts/install-thv.sh, which downloads the ToolHive CLI tarball from the releases/latest API response and executes it. That job holds contents: write and pull-requests: write and pushes commits to the PR branch, so a replaced release asset would run with those permissions.
The same script also runs in Vercel's buildCommand, so this isn't a new trust relationship for the repo, but the Actions job carries more consequence than the Vercel build does.
What would actually help
toolhive publishes a *.sigstore.json bundle per artifact (alongside toolhive_<version>_checksums.txt and SBOMs). Verifying the bundle with cosign against an expected identity would detect a replaced asset.
A checksum check is not a substitute: the checksums file comes from the same API response as the tarball URL, so anyone able to replace one can replace the other. It only guards a download that is already HTTPS.
Notes for whoever picks this up
- Don't pin the CLI to the release being documented. This workflow also runs for
toolhive-studio and toolhive-registry-server, whose tags have no thv asset.
- Decide whether verification lands in
install-thv.sh (covers Vercel and dev containers too, but adds a cosign dependency to the Vercel build) or in the Actions step alone.
- Needs an identity policy, not just
cosign verify-blob: the certificate identity and OIDC issuer have to be asserted, or verification proves only that something signed it.
Raised by Copilot on #1114 (thread), deferred as its own change.
.github/workflows/upstream-release-docs.ymlrunsscripts/install-thv.sh, which downloads the ToolHive CLI tarball from thereleases/latestAPI response and executes it. That job holdscontents: writeandpull-requests: writeand pushes commits to the PR branch, so a replaced release asset would run with those permissions.The same script also runs in Vercel's
buildCommand, so this isn't a new trust relationship for the repo, but the Actions job carries more consequence than the Vercel build does.What would actually help
toolhive publishes a
*.sigstore.jsonbundle per artifact (alongsidetoolhive_<version>_checksums.txtand SBOMs). Verifying the bundle with cosign against an expected identity would detect a replaced asset.A checksum check is not a substitute: the checksums file comes from the same API response as the tarball URL, so anyone able to replace one can replace the other. It only guards a download that is already HTTPS.
Notes for whoever picks this up
toolhive-studioandtoolhive-registry-server, whose tags have nothvasset.install-thv.sh(covers Vercel and dev containers too, but adds a cosign dependency to the Vercel build) or in the Actions step alone.cosign verify-blob: the certificate identity and OIDC issuer have to be asserted, or verification proves only that something signed it.Raised by Copilot on #1114 (thread), deferred as its own change.