registrystack / registrystack/registry-stack
Support authenticated replacement-instance bootstrap
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 2h 57m
- Merged PRs (30d)
- 128
Description
## Outcome
An operator can restore or replace a single-node Registry Stack instance from approved backup history without weakening anti-rollback protection, reusing an old instance identity incorrectly, or requiring an ad hoc signing ceremony during an outage.
This complements #203 and does not expand the 1.0 adopter-runtime PR. High-availability and multi-replica recovery remain in #507.
## Design checkpoint
Define the smallest authenticated proof that lets a fresh instance establish:
- the intended product lane and replacement instance identity;
- the accepted trust anchor and authenticated anchor history;
- the latest approved bundle sequence and hash;
- the matching database, audit, and correctness-state snapshot;
- the operator authorization for replacement rather than rollback or cloning.
## Security invariants
- A stale, partial, cross-lane, or cross-instance backup cannot become current.
- Replacement cannot use AcceptUnsigned, AcceptRollback, or another silent break-glass path.
- Trust anchors are pinned independently of the closure they authorize.
- Audit evidence records the old identity, new identity, approved history, and recovery decision without secret values.
- Product-owned exact verification completes before traffic admission.
## Definition of Done
- [ ] A versioned replacement-bootstrap artifact and ownership model are documented.
- [ ] Relay and Notary authenticate and consume it through closed product-owned actions.
- [ ] Backup inventory and #203 recovery procedures include every required authority and durable artifact.
- [ ] Tests cover valid replacement plus stale sequence, wrong lane, wrong instance, anchor swap, partial snapshot, replay, and mixed-generation rejection.
- [ ] A clean single-node restore exercise reaches exact verification before traffic.
## Non-goals
- Automatic disaster-recovery orchestration.
- Multi-replica fencing or failover.
- Bypassing normal signed approval and anchor-rotation procedures.
Contributor guide
Research direction
Begin with the #203 recovery procedures and the Relay and Notary paths that must authenticate and consume the replacement-bootstrap artifact. Trace the required backup authorities and durable artifacts, then use the listed rejection cases and clean single-node restore exercise to verify that exact verification completes before traffic admission.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authentication, authorization, backend, databases, security
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 32/100