Skip to content

Distribute recovery custody and harden RC identity - #119

Merged
nicoechaniz merged 11 commits into
mainfrom
rc/v0-release-candidate-20260816
Aug 16, 2026
Merged

Distribute recovery custody and harden RC identity#119
nicoechaniz merged 11 commits into
mainfrom
rc/v0-release-candidate-20260816

Conversation

@nicoechaniz

@nicoechaniz nicoechaniz commented Aug 16, 2026

Copy link
Copy Markdown
Contributor

Issue

Closes #118

Claim-ID: 95bc0e19-3134-4a37-909a-66a3f8d1d709
Deployment: not deployed

Outcome

Turns the merged V0 identity baseline into a pre-release candidate with genuinely separated recovery-holder stores and processes, keyless threshold aggregation, multi-head recovery handling, crash-safe holder publication, and least-authority runtime capabilities.

The runtime now requires ten disjoint operator profiles plus two dedicated host profiles: status exposes exactly the five authenticated host-status methods and curator exposes exactly the four curator methods. All twelve profiles have separate keys, slots, paths and configs and are covered by one Ed25519 runtime binding signed by the active root-authorized embodiment signing key. Bootstrap and ordinary/recovery rebirth emit the same closed binding. Single-store/all-seed ceremonies remain explicitly synthetic and outside the public operational path.

Invariants

  • Identity and provenance remain verifiable.
  • No private memory or credentials were added.
  • No compatibility is retained for unshipped pre-release ceremony/runtime formats.
  • Independent holders keep one recovery key per process/store; the aggregator is keyless.
  • Operator and host roles are disjoint, bounded, revocable and fail closed.
  • No host, production, SSH, live custody or physical action was performed.

Validation

Exact candidate: 96e9b112053b02e91d2f0f9add4b507c32058889
Tree: 38f3edb002ac52aac2d51fbf533cb58c38b813c5

Independent exact-head review passed capability-set cardinality and uniqueness, hostile cross-runtime swaps/relabeling, signed widening attempts, wrong origins/keys/paths, hard expiry/revocation, bootstrap and ordinary/recovery rebirth. The same checks passed from source and from the installed wheel.

Tests

  • Installed-wheel full suite: 600 passed, 37 intentional skips, 1414 subtests, exit 0.
  • Focused adversarial suite: 35 passed, 804 subtests.
  • Ruff, mypy, compile, Draft 2020-12 schemas, DM041 vectors/provenance and secret scan: clean.
  • Clean wheel installation and contract smoke: clean.
  • Package CI exercises the installed distributed daimon-genesis entrypoint; the removed centralized bootstrap command is absent.
  • Two isolated builds were byte-identical.
  • Reproducible wheel SHA-256: df96015fe2bea750c97dc994cdfaccb96ef1d775cd4de315454b6edf540d1548.
  • Reproducible sdist SHA-256: ba89a1d77ac8f664fdac3be177d7778d004fb0045d65a44b62289176f4b9c879.

Security and rollback

The principal security changes are removal of all-seed operational APIs, cryptographic runtime/capability binding, strict operator/host role separation, exclusive expiry boundaries, signed revocation high-water handling and idempotent crash recovery around holder publication.

Rollback before deployment is a normal revert of this PR. Existing merged V0 remains untouched until merge; there is no live state migration or compatibility promise. Physical custody, external participant consent and any deployment remain separate human gates.

@nicoechaniz
nicoechaniz merged commit 75b3480 into main Aug 16, 2026
13 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[DM-084] Distributed custody and RC identity hardening

1 participant