Surfaced while planning the layers migration (#102 follow-up, REQ-LAYERREPO-001 clause 5). Not a code defect — an operational one, and it changes what that clause can mean.
The finding
The pulseengine realm's rolling signing key was generated on 2026-08-07 in 7b5ccc5, whose own commit message records the whole custody model in one sentence:
Secret half exists only as the VARVE_ROLLING_KEY repo secret.
Verified:
- the key was never committed to this repository's history (no leak);
- no 128-hex key file exists anywhere on the maintainer's machine (
~/.varve, the repo tree, temp dirs, Documents, Desktop);
- GitHub repository secrets are write-only — a secret can be overwritten but never read back, by anyone, through UI or API.
So the only extant copy of the key that signs every layer in the pulseengine realm is inside one repository's Actions secret store, usable only by workflows in that repository.
What this costs
- The migration cannot move signing. REQ-LAYERREPO-001 clause 5 says varve's repository shall stop carrying any realm's signing secret. For this realm that is currently unsatisfiable: the secret cannot be copied into
pulseengine-layers, because it cannot be read out of here.
- A new key is not a workaround. Consumers pin
4e771dc62a08be89e3450f8cd807da58ff70af4a4e124ebf2d2b71684cfd9973 by hand. varve has no rotation and no revocation — nothing signs "this new root replaces the old one" and no consumer would check such a statement. Minting a fresh key strands every existing consumer.
- Loss is terminal for the realm. If that secret is deleted, or the repository is lost, the
pulseengine rolling line can never be signed again. Every consumer pinned to that root would be stuck on the last layer they installed, with no in-band way to be told why.
What must NOT be done
Do not extract the secret via a workflow. With write access to this repository it is technically possible to echo a secret into a log or artifact in chunks. Doing so would expose the root key to run logs and to anyone who can read the run — and because varve has neither revocation nor rotation, that exposure is permanent and unfixable. The realm would have to be abandoned. The inability to read the secret back is a property worth keeping, not an obstacle to route around.
What the docs already said, and what they did not
varve docs root-ceremony is honest about this root:
varve's own published root (trust-roots/) is labelled a provisional rolling key … it has no rotation, revocation or threshold story, and it is not the product of the ceremony REQ-CEREMONY-001 describes.
That is accurate. What was never drawn is the operational consequence: the same document mandates paper backup in two locations, split custody over the seed, an access log, and an annual read test — and this key has none of them. The gap between what the ceremony prescribes and how the provisional key is actually held was documented as "provisional" and never as "unrecoverable".
The honest way forward
- Keep depositing from
pulseengine/varve. The realm's contents already migrated to layer.toml in the public pulseengine-layers repo, which is the part that matters day to day. Only the signing step stays here.
- Amend REQ-LAYERREPO-001 clause 5 to say what is true: for the
pulseengine realm the secret cannot move before REQ-CEREMONY-001, because it cannot be read. A clause that cannot be satisfied should say so rather than sit open as though someone simply has not got to it.
- Fix it properly at the ceremony (REQ-CEREMONY-001, v1.0.0). That is where a root is generated air-gapped under a two-person rule with paper backup and a recorded transcript, and where custody can be placed deliberately instead of inherited from whichever repository happened to need it first.
- Until then, treat the secret as a single point of failure and say so — in
docs root-ceremony, beside the existing "provisional" note. A reader currently learns the root has no rotation story; they do not learn it has no backup.
The general lesson
An agent generated a production signing key and recorded, accurately, that the only copy was a CI secret. Nothing about that was hidden — it is in the commit message. But "the key exists only here" reads as a scoping note and not as "there is no backup and it can never be moved", which is what it actually means. A key with one write-only copy is not in custody; it is in escrow with no escrow agent.
Related: REQ-CEREMONY-001 (v1.0.0), REQ-LAYERREPO-001 clause 5, #106 (varve does not pin its own toolchain).
Surfaced while planning the layers migration (#102 follow-up, REQ-LAYERREPO-001 clause 5). Not a code defect — an operational one, and it changes what that clause can mean.
The finding
The
pulseenginerealm's rolling signing key was generated on 2026-08-07 in7b5ccc5, whose own commit message records the whole custody model in one sentence:Verified:
~/.varve, the repo tree, temp dirs, Documents, Desktop);So the only extant copy of the key that signs every layer in the
pulseenginerealm is inside one repository's Actions secret store, usable only by workflows in that repository.What this costs
pulseengine-layers, because it cannot be read out of here.4e771dc62a08be89e3450f8cd807da58ff70af4a4e124ebf2d2b71684cfd9973by hand. varve has no rotation and no revocation — nothing signs "this new root replaces the old one" and no consumer would check such a statement. Minting a fresh key strands every existing consumer.pulseenginerolling line can never be signed again. Every consumer pinned to that root would be stuck on the last layer they installed, with no in-band way to be told why.What must NOT be done
Do not extract the secret via a workflow. With write access to this repository it is technically possible to echo a secret into a log or artifact in chunks. Doing so would expose the root key to run logs and to anyone who can read the run — and because varve has neither revocation nor rotation, that exposure is permanent and unfixable. The realm would have to be abandoned. The inability to read the secret back is a property worth keeping, not an obstacle to route around.
What the docs already said, and what they did not
varve docs root-ceremonyis honest about this root:That is accurate. What was never drawn is the operational consequence: the same document mandates paper backup in two locations, split custody over the seed, an access log, and an annual read test — and this key has none of them. The gap between what the ceremony prescribes and how the provisional key is actually held was documented as "provisional" and never as "unrecoverable".
The honest way forward
pulseengine/varve. The realm's contents already migrated tolayer.tomlin the public pulseengine-layers repo, which is the part that matters day to day. Only the signing step stays here.pulseenginerealm the secret cannot move before REQ-CEREMONY-001, because it cannot be read. A clause that cannot be satisfied should say so rather than sit open as though someone simply has not got to it.docs root-ceremony, beside the existing "provisional" note. A reader currently learns the root has no rotation story; they do not learn it has no backup.The general lesson
An agent generated a production signing key and recorded, accurately, that the only copy was a CI secret. Nothing about that was hidden — it is in the commit message. But "the key exists only here" reads as a scoping note and not as "there is no backup and it can never be moved", which is what it actually means. A key with one write-only copy is not in custody; it is in escrow with no escrow agent.
Related: REQ-CEREMONY-001 (v1.0.0), REQ-LAYERREPO-001 clause 5, #106 (varve does not pin its own toolchain).