v0.4.0

See CHANGELOG.md for v0.4.0.

v0.3.2

0.3.2 — a binary can say which build it is, however it was built

Against 0.3.1, `go install github.com/vault-genome/vaultgenome-core/cmd/acpctl@v0.3.1`
produces a working binary that answers "acpctl 0.0.0-dev (commit none)". That is the
wrong answer from a project whose claim is that you can tell what you are running and
check it against a signed release, and it is what every reader following the README's
own install line was given.

The version and commit a binary prints now fall back to the module version and VCS
revision Go already embeds, only when the Makefile's -X stamps are absent; a stamped
value always wins, so `make build` and this release workflow print what they always
printed. The Dockerfile takes VERSION and COMMIT as build arguments, because
.dockerignore excludes .git and Go can embed no revision in an image build.

Behaviour is otherwise 0.3.1's. Bundle format, audit schema and policy schema: unchanged.

v0.3.1

0.3.1 — the release pipeline's signing step, and nothing else

0.3.0 is tagged and the module is served at that version, but its release run
stopped at "Sign binaries": the actions bump of #33 moved cosign-installer to
v4, which installs cosign 3, and cosign 3 writes the Sigstore bundle format by
default and ignores --output-signature / --output-certificate. 0.3.0 therefore
has no release assets. This release pins cosign 2.6.5, so the assets and the
documented verification commands stay what they were; the move to bundles is
KNOWN_ISSUES #15. The code is 0.3.0's.

v0.2.1 — the reference release: static binaries, rebuilt byte for byte from another host

v0.2.1 — the reference release: static binaries, rebuilt byte for byte from another host

The code of v0.2.0 (its notes) with three changes:

• Static binaries. Built with CGO_ENABLED=0: they run on any linux/amd64 without a libc to match, and anyone rebuilds them byte for byte from any host with the pinned Go (1.27.0) from a git checkout of the tag — the post-release check in docs/operator/05_release_procedure.md §5 names the exact command, and it was run from macOS against these artifacts (v0.2.0's binaries were built with cgo on the runner, which is why this release exists).
• Dependencies: etree 1.8.0, testify 1.12.1, bbolt 1.5.0 (Dependabot, the gate green); the dependency justifications no longer carry a version — go.mod does.
• Dependabot keeps Go modules and GitHub Actions current and opens no pull requests against the worker's measured Python runtime.

Four signed binaries (sagvd, acpctl, acp-bootstrap, acp-compute), each with a keyless cosign signature and certificate, an SPDX SBOM signed the same way, and a SLSA level 3 provenance attestation.

Verify what you downloaded

cosign verify-blob --signature sagvd.sig --certificate sagvd.cert \
  --certificate-identity-regexp '^https://github\.com/vault-genome/vaultgenome-core/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com sagvd
slsa-verifier verify-artifact sagvd --provenance-path multiple.intoto.jsonl \
  --source-uri github.com/vault-genome/vaultgenome-core --source-tag v0.2.1
git verify-tag v0.2.1

Rebuild it yourself

git clone https://github.com/vault-genome/vaultgenome-core.git && cd vaultgenome-core && git checkout v0.2.1
GOOS=linux GOARCH=amd64 make build VERSION=v0.2.1 COMMIT=$(git rev-parse HEAD)
sha256sum bin/sagvd bin/acp-compute bin/acpctl bin/acp-bootstrap   # equal to the released files

Verified after publication

Run from a macOS machine against these artifacts on 2026-09-17 (the procedure's §5): cosign verify-blob on the four binaries and their SBOMs — 8 of 8 OK; slsa-verifier on the four binaries against the provenance — 4 of 4 OK; git verify-tag v0.2.1 — good signature by the pinned release key; the rebuild from a git checkout of the tag with Go 1.27.0 (GOOS=linux GOARCH=amd64 make build VERSION=v0.2.1 COMMIT=be815b03049bec65d4b08ffde6136118fa6e8e51) — byte-identical for all four binaries.

File	SHA-256
sagvd	8f8289c426cc198a9a5b895bc1ca20f82e25d93a00da8d37491fd1b93b9fada1
acp-compute	e09392dbaf530fae511af655be3ad98e43bb0d1a87374892084dc5b5617eda27
acpctl	c5c1453d8b15aea553b65c8f23e0a168543545f9ac727d01a585acaa9c07afe6
acp-bootstrap	2984812e72528d70f678ff1920ae73e9ed5691e48883b4880c19a77f202211ed
multiple.intoto.jsonl	8838881da426be2a9df66f38da5e2cf25ef0a008f7b3705ad321be581c40e6e2

v0.2.0 — two days of hardware, on the record

v0.2.0 — two days of hardware, on the record

Four signed binaries (sagvd, acpctl, acp-bootstrap, acp-compute) built reproducibly, each with a keyless cosign signature and certificate, an SPDX SBOM signed the same way, and a SLSA level 3 provenance attestation (multiple.intoto.jsonl). Full details in CHANGELOG.md.

Highlights

• A real fine-tuned model survives its machine and comes back gated. The worker restores the sealed genome's model in memory and the authority judges it through the door; the nine governed stages run for every job with each decision on the signed, hash-chained audit log before it takes effect.
• Five continuity drills on live confidential hardware in two clouds. A model under attack on an AMD SEV-SNP VM fails over to another SEV-SNP VM (RTO 16.81 s), to an Azure confidential H100 across the Internet (RTO 24.99 s), to an Intel TDX Trust Domain (RTO 24.09 s); the authority itself on TDX; eight policies against one attack — seven refused for seven stated reasons, one move.
• No secret file bare on a host. The escrow key lives only sealed to the chip (or the vTPM on TDX and the Azure GPU host); every seed, the session sealing key, the TLS keys, the tokens and the sentinel's seed are sealed in place; a sealed file taken to another chip does not open.
• The GPU is evaluated by this verifier, not only by NVIDIA. The H100's attestation report — signature, chain to NVIDIA's root, firmware id, every measurement against NVIDIA's signed manifests, the chain's revocation asked of NVIDIA's OCSP responder — and what was checked is on the audit record that admits the worker or releases the key.
• 32B on a confidential GPU. Qwen2.5-32B-Instruct fine-tuned, sealed, restored and gated EXACT (16/16) on an Azure H100 in confidential-computing mode, over the Return Path. The integer door gives the same bytes on a Xeon and an L4 at 0.5B and 7B.

Every number above links to its evidence in VERIFIABLE-CLAIMS.md (C13–C26), and what we do not claim is listed just as carefully.

Compatibility

The genome v3 bundle format and the audit schemas are unchanged; new audit payload fields and config fields are optional; gpu_policy.evaluation: "own" is admitted; key files may be sealed and bare files still load. The Return Path's frame cap moved from 16 MiB to 128 MiB: both ends must run this release or later for a genome over 16 MiB. Go 1.26.

Verify what you downloaded

cosign verify-blob --signature sagvd.sig --certificate sagvd.cert \
  --certificate-identity-regexp '^https://github\.com/vault-genome/vaultgenome-core/\.github/workflows/release\.yml@refs/tags/v' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com sagvd
slsa-verifier verify-artifact sagvd --provenance-path multiple.intoto.jsonl \
  --source-uri github.com/vault-genome/vaultgenome-core --source-tag v0.2.0
git verify-tag v0.2.0

v0.1.0

VaultGenome core v0.1.0