nicweyand/argand-site-registry
1
0
Fork 0
Code Issues Pull requests Projects Releases 7 Packages Wiki Activity Actions

release: implement site registry v0.4 trust pipeline

Browse source
This commit is contained in:
Nic Weyand 2026-09-13 12:22:05 -04:00
commit e26efc19fa
Signed by: nicweyand
SSH key fingerprint: SHA256:2te+ycJIQON/Wo/dH6+ZkFSQ4HnHWpetV2azx9E65dQ
67 changed files with 10698 additions and 640 deletions
Download patch file Download diff file Expand all files Collapse all files

38
docs/adr/0003-votes-revocations-and-publishers.md Normal file
View file

@ -0,0 +1,38 @@
# ADR 0003: Signed votes, sticky revocations, and publisher separation
Status: Accepted, 2026-09-13.
Reviews are immutable signed votes compiled under a receipt-bound policy epoch.
The reference policy requires two reviewer identities, two independent groups,
and two physical SSH keys. One revocation blocks the exact subject until every
approval in a fresh quorum explicitly references all active revocation IDs.
Publisher identity and key must be separate from every reviewer vote.
Changing the policy epoch never clears a retained revocation; a fresh quorum
under the new policy must explicitly supersede it.
Trusted writer acceptance time bounds validity. Reviewer timestamps cannot
backdate eligibility or extend an approval beyond 90 days after acceptance.
Risk-class thresholds may raise the base name, edge, or equivalence quorum for
`source_conflict` and `dangerous_drift`. The reference policy also holds those
edges in disputed or probationary state until the underlying risk clears.
Emergency feeds are cumulative, use the separate
`argand-site-registry-revocations` SSH namespace, retain superseded revocation
IDs, and can be applied to a compatible pinned generation before its replacement
arrives. Cross-generation feeds only add blocks. Reinstatement requires the exact
full generation containing the signed superseding quorum, and feed artifacts must
be refreshed at least every seven days.
## Rejected alternatives
Latest-decision-wins lets one later approval erase a revocation. Counting aliases
of one key as separate reviewers does not provide independence. Letting a release
publisher contribute approvals collapses review and publication into one actor.
## Compatibility
Legacy decisions remain available only under the explicit v0.3 compatibility
policy. Strict receipts bind the policy and reviewer trust-root digests. A policy
change creates a new epoch and old approvals become stale rather than being
silently reinterpreted.