docs(secrets): name the second recipient's holder, and fix the roadmap's rejection (#294) - #397
Merged
Merged
Conversation
…p's rejection (#294) ADR-0024 built the mechanism — make secrets-add-recipient, per-recipient proof, the runbook text — under #106, and deliberately left one question open: who else should be able to open the estate's secrets. #294 exists to answer it, and the answer is the technical second named on the break-glass card, holding a recipient of their own generated where they keep it. That satisfies ADR-0023's off-estate constraint and the successor-handover case in one move. The location stays out of the repository, as the first key's does. Written in the honest form: whether their key is in .sops.yaml is read from the file, not from the paragraph, because the keypair is generated offline by hand and this commit cannot add it. The handover runbook's recovery path becomes a call to a named role rather than "obtain the key from the person you are replacing", which fails in exactly the case a trustee exists for. The roadmap's #94 entry still read "Rejected: a second age recipient" with no pointer to ADR-0024 — the one place in the documents that contradicted it. Narrowed to what was actually rejected: a recipient on oracle. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Gerrrt
force-pushed
the
gerrrt/second-recipient-holder-294
branch
from
September 8, 2026 06:26
8631827 to
6ae61f4
Compare
7 tasks
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.
The decision half of #294: where the second age recipient lives. The mechanism is already built (ADR-0024, #297, under #106); this PR writes down the holder and fixes the one document that still contradicted the ADR.
Decided 2026-09-08: the second recipient is held by the technical second named on the break-glass card, generated where they keep it, never on the monitoring host. Satisfies ADR-0023's off-estate constraint and the handover case in one move;
oraclestays struck, per ADR-0023/0024.Changed:
back-up-the-age-key.md§What this still does not solve — the "One person" paragraph becomes the decision, in the form that reads the key's presence from.sops.yamlrather than asserting it.successor-handover.md§If you do not have the age key — the recovery path is a call to that role; a successor adds a third recipient, not a first.docs/roadmap.md— the Decide what oracle is for #94 entry's flat "Rejected: a second age recipient" narrowed to what was rejected (a recipient onoracle) with a pointer to ADR-0024.Not in this PR, and cannot be: the keypair and the re-key. Steps are on the issue.
.sops.yamlstill carries one real recipient until they are done.Checks:
make check-docs,scripts/lint.sh.Refs #294, #106.
🤖 Generated with Claude Code