stacklok / stacklok/docs-website
Verify the ToolHive CLI signature before executing it in CI
Nobody has claimed this yet.
- Dominant language
- TypeScript
- Stars
- 4
- Forks
- 3
- Avg merge
- 1d 7h
- Merged PRs (30d)
- 41
Description
.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-studioandtoolhive-registry-server, whose tags have nothvasset. - 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.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with .github/workflows/upstream-release-docs.yml and scripts/install-thv.sh, then trace how the latest ToolHive release asset is selected and executed. Decide where verification belongs and define the expected certificate identity and OIDC issuer, including the workflows for toolhive-studio and toolhive-registry-server. Done means a replaced asset is rejected before execution without pinning the CLI to the documented release.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- github-actions, shell
- Domain
- ci-cd, security
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100