What and why
Add a second age recipient to .sops.yaml and re-key secrets/observability.sops.yaml, so that decryption does not depend on one key held by one person.
This is the implementation half of #106, which states the risk and stops where the decision starts: ".sops.yaml supports multiple recipients, so the mechanism costs nothing; what it needs is somewhere to put the second key." That sentence is still the whole of the work. #106 stays open as the risk; this issue is where the second key's home gets decided and the re-key gets done.
Three things have changed since #106 was filed on 2026-08-21, and each of them pushes the same way.
ADR-0023 makes this a dependency rather than a nice-to-have. It requires an off-estate encrypted copy of the household's photographs and documents, and then rules on the key: "the off-estate copy is encrypted, and the key that opens it cannot be the one only the operator holds. #106 is this same problem one layer down." A single-holder key is now blocking a decision that is already accepted.
ADR-0023 also rules out the home #106 proposed for it. #106 suggests oracle — "an idle machine looking for a purpose, and holding a second recipient is a job that suits a machine with a slow disk and nothing else to do." ADR-0023 checked exactly that pattern and rejected it: oracle is 10.0.99.30, "the same VLAN, the same rack, the same power feed and the same room", so "every failure that motivates this document — fire, theft, flood, a mistake made with root, or simply the operator being unreachable — reaches both boxes in one event. The existing pattern therefore does not satisfy this constraint, and it is close enough to look as though it does." That reasoning is about the household archive, but it transfers to a decryption key without modification. oracle should be struck from #106's suggestion rather than inherited from it.
The handover page now depends on the answer. docs/runbooks/successor-handover.md (#124) tells an arriving operator that a successor who cannot decrypt has nothing, and has to point at #106 as an open issue rather than at a procedure. Right now the honest instruction to a technical trustee is "obtain the key from the person you are replacing", which fails in precisely the case a trustee exists for.
The decision this issue exists to make
Where the second key lives. The mechanism is settled and cheap; this is the part that is not.
| Option |
For |
Against |
| An offline key held by the technical second named on the break-glass card |
Satisfies ADR-0023's off-estate constraint and the handover case in one move; the person already exists and is already named |
Depends on that person storing it correctly, and make secrets-verify-backup cannot be run on their behalf |
| A second offline key stored in a different physical location, same holder |
Survives fire, theft and flood at the rack |
Does nothing for the operator being unreachable, which is half of what ADR-0023 is about |
oracle |
#106's own suggestion; zero human dependency |
Ruled out by ADR-0023's reasoning above — same rack, same power, same room |
The counter-argument is in back-up-the-age-key.md and should be answered rather than dropped: "It is worth doing on the day the lab stops being a one-person project, and not before — every extra recipient is another key that can leak." The claim to weigh is whether ADR-0023 and a named technical second are that day.
Mechanism, once the home is chosen
Already documented in secrets/README.md; repeated here so the issue is self-contained.
age-keygen the second keypair offline, never on the monitoring host.- Add its public half to
.sops.yaml as an additional recipient.
sops updatekeys secrets/observability.sops.yaml from a host that can already decrypt.- Prove the new key actually opens it:
make secrets-verify-backup KEY=<the new key>. That target refuses the live key by device and inode and blanks the environment, so a pass means the second key did the work.
- Confirm the first key still decrypts too — a re-key that drops a recipient is the failure mode here.
Done when
Whether ADR-0023's off-estate household archive key is this key or a separate one is in scope for the discussion here, since ADR-0023 ties them together.
What and why
Add a second age recipient to
.sops.yamland re-keysecrets/observability.sops.yaml, so that decryption does not depend on one key held by one person.This is the implementation half of #106, which states the risk and stops where the decision starts: "
.sops.yamlsupports multiple recipients, so the mechanism costs nothing; what it needs is somewhere to put the second key." That sentence is still the whole of the work. #106 stays open as the risk; this issue is where the second key's home gets decided and the re-key gets done.Three things have changed since #106 was filed on 2026-08-21, and each of them pushes the same way.
ADR-0023 makes this a dependency rather than a nice-to-have. It requires an off-estate encrypted copy of the household's photographs and documents, and then rules on the key: "the off-estate copy is encrypted, and the key that opens it cannot be the one only the operator holds. #106 is this same problem one layer down." A single-holder key is now blocking a decision that is already accepted.
ADR-0023 also rules out the home #106 proposed for it. #106 suggests
oracle— "an idle machine looking for a purpose, and holding a second recipient is a job that suits a machine with a slow disk and nothing else to do." ADR-0023 checked exactly that pattern and rejected it:oracleis10.0.99.30, "the same VLAN, the same rack, the same power feed and the same room", so "every failure that motivates this document — fire, theft, flood, a mistake made with root, or simply the operator being unreachable — reaches both boxes in one event. The existing pattern therefore does not satisfy this constraint, and it is close enough to look as though it does." That reasoning is about the household archive, but it transfers to a decryption key without modification.oracleshould be struck from #106's suggestion rather than inherited from it.The handover page now depends on the answer.
docs/runbooks/successor-handover.md(#124) tells an arriving operator that a successor who cannot decrypt has nothing, and has to point at #106 as an open issue rather than at a procedure. Right now the honest instruction to a technical trustee is "obtain the key from the person you are replacing", which fails in precisely the case a trustee exists for.The decision this issue exists to make
Where the second key lives. The mechanism is settled and cheap; this is the part that is not.
make secrets-verify-backupcannot be run on their behalforacleThe counter-argument is in
back-up-the-age-key.mdand should be answered rather than dropped: "It is worth doing on the day the lab stops being a one-person project, and not before — every extra recipient is another key that can leak." The claim to weigh is whether ADR-0023 and a named technical second are that day.Mechanism, once the home is chosen
Already documented in
secrets/README.md; repeated here so the issue is self-contained.age-keygenthe second keypair offline, never on the monitoring host..sops.yamlas an additional recipient.sops updatekeys secrets/observability.sops.yamlfrom a host that can already decrypt.make secrets-verify-backup KEY=<the new key>. That target refuses the live key by device and inode and blanks the environment, so a pass means the second key did the work.Done when
back-up-the-age-key.mdexplains why)..sops.yamlcarries two recipients andsecrets/observability.sops.yamlis re-keyed.make secrets-verify-backup.back-up-the-age-key.md§"What this still does not solve" updated — it currently defers this to "the day the lab stops being a one-person project", which will be the wrong text once this lands.successor-handover.md§"If you do not have the age key" updated to describe a second recipient rather than a one-key recovery path.secrets/README.md's second-host paragraph reviewed — it describes this same procedure for a different reason and should not end up contradicting the new text.Whether ADR-0023's off-estate household archive key is this key or a separate one is in scope for the discussion here, since ADR-0023 ties them together.