CRITICAL: epoch fence bypassed by DELETE-only ops (update_new_op_authors misses delete-set authors)

[cuttlefisch]

Found + VERIFIED in the impl-pass security review over the merged #163 fence. CRITICAL.

Bug

shared/sync/src/kb.rs::update_new_op_authors attributes new-op authors by diffing yrs state vectors
(before/after apply) ∪ the update's own SV. In YATA a deletion is a tombstone in the delete-set, not a
clock-advancing struct — so a pure-delete update advances no client's clock and contributes nothing to
either signal. update_new_op_authors returns [], enforce_epoch_fence finds no stale author → Ok.

Verified

A probe (stale client deletes a node body via set_body("")) returns authors = [] for both an existing-lineage
client and a fresh client:

PROBE pure-delete authors = []
PROBE client-999 delete authors = []

Attacker path

A demoted-not-removed (or viewer-era) client at a stale epoch authors a DELETE of base content. kb_access(Edit)
passes (they're a current editor), enforce_epoch_fence passes (delete → no authors) on both the hub
kb/node_update and the mesh dialer paths (both consume update_new_op_authors). The censoring deletion lands +
broadcasts. (A removed member is still caught by admit/NotAMember on the signed path; this is the
demoted/unsigned-hub gap.)

Fix

In update_new_op_authors, also attribute delete-set authors: decode yrs::Update::decode_v1(update), iterate
its delete_set per-client ranges, and union every client id whose deletions aren't already covered by
base_state's delete-set. Add regression tests: a pure remove_range/remove_tag/set_body("") under a stale
client id is reported, and an end-to-end enforce_epoch_fence test that a stale-epoch delete is REJECTED.

Test gap (principle #14)

Every B-19/B-20 fence test uses set_title/set_body with non-empty text — remove_range THEN insert, and the
insert masks the gap. None exercises a delete-dominant op. The chosen inputs all happen to insert (the "unicorn
value" failure mode).

[cuttlefisch]

⚠️ Correction — the proposed "attribute delete-set authors" fix is WRONG (verified)

A probe shows yrs delete-set keys are the deleted content's ORIGINAL author, not the deleter. Client 999
deleting client-1's content produces:

DELETE-SET = { 1: [[4..21]] }     // keyed by 1 (content author), NOT 999 (the deleter)
UPDATE blocks SV = {}             // empty — no struct/clock advance

So attributing delete-set client_ids would:

1. Attribute the deletion to the content's author (1), not the actor (999) — useless for catching the
   stale-epoch deleter; and
2. Reject every legitimate cross-author deletion (a current member deleting anyone else's content whose
   client_id ≠ their current-epoch client_id) → breaks normal collaboration. Do NOT implement this.

Revised analysis (severity → HIGH, not CRITICAL)

yrs deletions carry no deleter identity — they're unattributable at the CRDT layer, so update_new_op_authors
structurally cannot fence them. But the practical exploit surface is narrower than first stated:

• A viewer can't author edits at all (kb_access(Edit) denies viewers) — not a vector.
• A removed member is caught by admit/NotAMember (signed) or the role gate — not a vector.
• Residual: a member whose epoch rotated but who is still a current Editor (e.g. removed-then-readmitted, or
  epoch-bumped by a rotation) replaying a pre-rotation deletion. An integrity edge (re-applying stale
  deletes / censorship), not an access-control or confidentiality breach.

Real fix options (need design, do not rush)

• On a fenced/E2e KB, require node updates to be signed and reject delete-bearing updates lacking a
  current-epoch signed header (close the unsigned-hub-delete path). The signed admit epoch check then
  attributes the deleter.
• Or carry an explicit deleter-attribution wrapper at the op-set / content-op layer (the op-set op already has a
  client_id-stamped outer op for E2e — for an E2e KB the delete IS wrapped in a signed, epoch-stamped outer op,
  so E2e KBs may already be covered; the gap is the plaintext/unsigned node path). Confirm whether E2e
  (sealed) deletes are already fenced via the outer op's client_id before sizing the fix.

[cuttlefisch]

Verified: E2e KBs ARE covered (regression-tested); plaintext-path residual remains

Probed + added a permanent regression guard (update_new_op_authors_attributes_a_sealed_delete_to_the_seal_client, on PR #172): on an E2e KB a deletion is sealed into a client-id-stamped outer op-set op, so
update_new_op_authors reports the (stale) seal client_id and the ADR-023 fence rejects a stale-epoch
sealed delete — even though the inner op is a pure, otherwise-unattributable yrs delete. With #168's fail-closed
seal making E2e KBs always seal, the deletion-fence gap is closed for E2e KBs.

Residual (still open, deferred): on the plaintext/unsigned node path, a pure delete is unattributable
(yrs tombstones carry no deleter). Narrow exploit (an epoch-rotated-but-still-Editor replaying a pre-rotation
delete — viewers can't edit, removed members are caught by admit/role). The real fix needs deleter
attribution at a higher layer (e.g. require signed ops + reject delete-bearing updates without a current-epoch
signed header on a fenced KB). Keeping this issue open for that design; the E2e exposure is resolved.