feat(tee-vm): dedicated snp-tools release stream, pinned in build-config - #637
Merged
Conversation
snp-digest changes far less often than the VM image, so publish it once as a snp-tools-v* GitHub release (new amdsev-snp-tools-release workflow: test, build --locked, smoke-run, publish snp-digest-<tag> + .sha256) instead of rebuilding it inside every tee-vm release. Consumers pin one release via SNP_DIGEST_RELEASE + SNP_DIGEST_SHA256 in build-config — trusted because build-config is versioned in git at the consuming tag. The tee-vm release pipeline downloads the pinned binary (checksum-verified) to compute the published measurement, and install.sh downloads the same binary on SNP hosts, so measurement verification needs no Rust toolchain; the publisher and every verifier run identical code. Empty pins (and tags predating them) fall back to building from source — the prebuilt is a convenience copy, never the trust root, and its checksum stays out of build-info.txt so reproduce-release.sh is unaffected. Also hardens all installer downloads with connect timeouts, retries, and a transfer-speed floor — a rate-limited GitHub API call used to hang the install indefinitely. Rollout after merge: dispatch amdsev-snp-tools-release (0.1.0), then bump the two build-config pins from the release notes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
kariy
added a commit
that referenced
this pull request
Jul 15, 2026
Sets the two `build-config` pins introduced in #637 to the freshly cut [`snp-tools-v0.1.0`](https://github.com/dojoengine/katana/releases/tag/snp-tools-v0.1.0) release. The SHA-256 matches both the published `.sha256` asset and a locally re-downloaded copy of the binary. From the next `tee-vm-v*` release onward, the release pipeline and `install.sh` download this pinned verifier instead of building `snp-tools` from source. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
Every
tee-vm-v*release rebuiltsnp-digestfrom scratch just to compute its measurement, and #636's installer additionally required a Rust toolchain on every SNP host to verify measurements. The verifier changes far less often than the VM image — it should be released once and reused.What
amdsev-snp-tools-releaseworkflow (dispatch with a version):cargo test --locked, build, smoke-run, publishsnp-tools-v<X.Y.Z>withsnp-digest-<tag>+ a bare-hex.sha256. Release notes print the exact pin lines to adopt it.build-configpins the chosen release (SNP_DIGEST_RELEASE+SNP_DIGEST_SHA256) — the checksum is trusted because build-config is versioned in git at the consuming tag, so the pin travels with every tee-vm tag.amdsev-release.yml: "Build snp-tools" → "Obtain snp-digest": downloads the pinned binary (checksum-verified, smoke-run) to compute the published measurement, so the publisher and every verifying host run the identical binary; release notes name the pinned verifier. Empty pins fall back to the source build.install.sh: reads the pins from the installed tag'sbuild-config(sed extraction, not sourcing), downloads once with checksum + smoke-run gates, caches across re-runs, and drops the binary whereverify-build.sh's discovery already looks. Fallback chain: pinned prebuilt → cargo build → checksum-only with a loud warning. Also hardens all downloads with connect timeouts, retries, and a 1 KB/s speed floor — a rate-limited GitHub API call used to hang the install indefinitely.build-info.txtsoreproduce-release.shis unaffected. Docs updated (release-pipeline.mdstream + runbook,install.mdprerequisites).Validation
shellcheck clean (CI set), 46 unit tests green (
test-install.sh, incl. newbuild_config_getextraction tests), actionlint clean on both workflows, and a live--dry-runinstall against the just-publishedtee-vm-v0.3.0+katana-v1.8.0-rc.8(no pins there yet → correct source-build fallback messaging).Rollout
amdsev-snp-tools-releasewith0.1.0.build-configpins from the release notes — from then on neither the release pipeline nor any SNP host buildssnp-digest.🤖 Generated with Claude Code