Witness protocol remediation — tracking
- Dominant language
- Rust
- Stars
- 3
- Forks
- 0
- Avg merge
- 1d 42m
- Merged PRs (30d)
- 11
Description
Tracking issue for the witness protocol remediation work on `campaign/server-witness-remediation`, targeting `server`.
## Why
A post-merge audit of the witness and multi-server work found one defect shape repeated across every part of it: a test whose name asserts a broad invariant while its body exercises only the narrow input shape the implementation happens to handle. Six instances. Two were confirmed by tests that reproduce them.
Concretely, the confirmed defects were: registration authorization bypassable in three distinct shapes including the delete verb, which no test covered at all; a witness that signs freshly-timestamped attestations over arbitrarily stale state because every sync failure is discarded; an upstream patch response consumed without verifying it came from the expected authority, so entries can be silently withheld; and a single malformed entry permanently wedging a witness's sync with no external signal.
The remediation is not only to fix those. It is to close the *class* — replacing enumerated adversarial cases with properties that range over the input space, so the next unanticipated shape is covered rather than discovered.
## Scope
- **Registration authorization** — audit the fix for class-closure, move the self-authorization check from string matching to a parsed type so an unanticipated identifier shape cannot be admitted, and replace the enumerated cases with a property over the shape space and both verbs.
- **Cross-witness consistency** — audit the equivocation test, replace it with a property over the type space and three-or-more witnesses, remove the witness threshold, and widen key-validity tests that assert against local copies rather than the functions under test.
- **Sync channel** — replace a return type that reports success on every failure and is discarded by both callers; eliminate the permanent wedge; and authenticate the channel so an on-path party cannot withhold entries. The signature must bind the entries served, not merely exist.
- **Resync anchor** — replace the sequence-number anchor with a content-addressed digest. A counter is not an injective commitment over content, so two divergent branches reach the same anchor and it cannot identify a history.
- **Broad audit** — a read-only sweep of the prior work for further defects of the same character, plus establishing empirically whether push-on-mutation fanout delivers at all.
## Out of scope, each blocked on a specific open question
- **Staleness serve-policy** — what a witness does once it knows it is stale. Semantics not yet settled.
- **Envelope completeness** — whether a patch signature can assert that entries are *all* current entries. Structurally constrained: the trust model forbids a standing consistency claim, so the obvious form is not available. See #140.
- **Resync proof-of-possession** — specified but unimplemented, and both of its consumers are themselves open.
- **Fanout remedy** — the topology question is entangled with the gossip section under revision.
## Open specification questions
- #139 — what a witness attestation asserts about currency
- #140 — which root anchors the resync, and what a patch signature commits to
## Out-of-scope findings
Findings discovered during this work that will not be fixed here get their own issue, linked from this one, rather than being dropped.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reading the campaign/server-witness-remediation work and the open specification questions in #139 and #140; the issue names no files or tests. Then trace the listed workstreams, beginning with the confirmed defect shapes and the scope bullets. Done means closing the specified defect classes with properties over their input spaces, completing the broad audit, and tracking out-of-scope findings separately.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- authentication, security
- Issue type
- Bug
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100