varve v0.32.1

⚠ The rolling trust root changed in this release

4e771dc6… → 7d3b892e…

If you keep the varve-realms.toml you already have, nothing breaks and you need do nothing. Your installs are untouched — varve partitions its store by trust root, so the new realm occupies its own namespace (realms/a8ca9eb8fec663e6) and cannot collide with anything you have installed.

If you take the new varve-realms.toml, you must move your pin in the same change. Every layer published from 2026.08.0 through 2026.09.1 was signed by the old root and does not verify against the new one. Taking the file alone leaves you pinned to a layer your realm can no longer verify:

error: manifest signature verification failed: … No valid signatures

The first layer signed by the new root will be 2026.09.2. Until it is published, the correct action for a consumer is to do nothing.

Why the root rotated

It existed only as a write-only GitHub Actions secret in this repository, created 2026-08-07 and never copied anywhere. GitHub secrets cannot be read back by anyone, including the org owner — so nobody held it and nobody could move it. That is #110, filed three weeks earlier as a risk and collected here as a fact: it blocked pulseengine-layers, which needs the same key to deposit, and there was no way to give it one.

varve-realms.toml has always said this root is provisional until the v1.0 ceremony, so this is the planned event happening sooner, not a promise broken. Rotated rather than recovered: a workflow that decrypts a secret out to its owner manufactures a durable copy and a reusable exfiltration path in order to postpone a rotation that was already scheduled. The new key was generated offline by the maintainer and never seen by an agent.

On the version number

There is no code change from v0.32.0 — no behaviour, no CLI, no format. The patch number describes the tool, which is unchanged. It does not describe the impact, which is larger. This release exists to publish two assets: the rotated rolling.pub and the varve-realms.toml naming it.

Verify this release yourself

The claim is that the published realm and the published key name the same root. To refute it:

gh release download v0.32.1 --repo pulseengine/varve -p rolling.pub -p varve-realms.toml
test "$(cat rolling.pub)" = "$(sed -n 's/^trust-root = "\(.*\)"/\1/p' varve-realms.toml)" \
  && echo AGREE || echo "DISAGREE — this release is wrong"

And the usual supply-chain checks:

cosign verify-blob \
  --certificate-identity-regexp 'https://github.com/pulseengine/varve/.github/workflows/release.yml@.*' \
  --certificate-oidc-issuer 'https://token.actions.githubusercontent.com' \
  --bundle SHA256SUMS.txt.cosign.bundle SHA256SUMS.txt

sha256sum --ignore-missing -c SHA256SUMS.txt
gh attestation verify varve-v0.32.1-x86_64-unknown-linux-gnu.tar.gz --repo pulseengine/varve

Both rolling.pub and varve-realms.toml are covered by SHA256SUMS.txt.

The gap this rotation exposed — REQ-ROTATE-001

varve committed this root twice: as key material in trust-roots/rolling.pub (shipped as a release asset, used by deposit-layer.yml as VARVE_TRUST_ROOT) and as a fingerprint in varve-realms.toml (downloaded by consumers, authoritative over the environment). Nothing compared them.

A half-finished rotation fails in the worst available way: CI signs a deposit against the key file and verifies against that same file, so it passes green — while every consumer resolving the realm rejects the identical layer as unsigned, downstream, after the release ships. This release adds the missing oracle, which runs the real realm parser over the real committed file. It was confirmed red against a realms file rotated on its own.

The lesson worth keeping is not "rotate keys". It is that a root which cannot be backed up or moved is a root you will eventually lose — and that the issue predicting exactly this sat open while the thing it predicted happened.

---

What's Changed

• Layer 2026.09.1: meld 0.53.0, synth 0.61.0, and varve-producer in the layer by @avrabe in #128
• Deposit: publish-check ran from the wrong directory, and mislabelled the failure by @avrabe in #129
• Rotate the provisional rolling root (4e771dc6… → 7d3b892e…) by @avrabe in #136

Full Changelog: v0.32.0...v0.32.1