E2e: enabling encryption does not re-seal already-shared content (re-encryption-on-enable)

[cuttlefisch]

Surfaced while fixing the fail-closed seal (#168/#170).

Gap

The natural flow is: create KB with content → kb-share → kb-set-encryption e2e. The share transmits node
content as plaintext (legitimately — the KB is unencrypted at that point), so the daemon holds plaintext
kb:{node} docs. Enabling E2e does NOT retroactively re-seal that existing content — only subsequent EDITS
seal (via the now-fail-closed kb/node_update). So historical, un-edited node content stays readable by the
key-blind daemon after enable.

#170 stops the re-share from RE-leaking, and #168 stops new edits from leaking — but neither retro-protects the
content that was shared before enable.

Fix (re-encryption-on-enable)

When kb-set-encryption e2e runs (KbSetEncryption handler, after the content key is generated): re-seal every
existing node — author a sealed kb/node_update (full node state) for each node so the daemon's kb:{node}
becomes the op-set, replacing the plaintext. The editor side iterates the KB's nodes; the network task seals
them under the new key. Joiners then receive only ciphertext.

Workaround until then (document)

Enable E2e on an EMPTY KB before adding content, or treat pre-enable content as not-confidential.

Severity

HIGH — the natural share→enable flow leaves existing content unprotected. Not an active new-content leak
(those are #168/#170, fixed), but a confidentiality gap for historical content.

[cuttlefisch]

Mechanism confirmed (single-host harness, scripts/collab-encrypted-e2e.sh)

Diagnosing the E2E join-decrypt failure surfaced this gap's exact mechanism. A node shared plaintext, then E2e-enabled, then edited (sealed), never delivers its sealed content to a joiner:

1. At share, the daemon's kb:<kb>:<node> doc is a plaintext KbNodeDoc whose lineage uses the node's deterministic client_id (post-KB collab: owner editing an IMPORTED+shared node is rejected by the epoch fence (imported client_id lineage) #166 = derive_kb_client_id(fp, 0)).
2. On a sealed edit, build_kb_node_update_request seals into an op-set whose outer op is stamped with derive_kb_client_id(fp, epoch) — the SAME client_id as the plaintext lineage (epoch 0). The daemon logs OVERLAP: update client already in local state vector client_id=…; yrs treats the colliding-clock ops as already-seen and skips them, so encode_state(kb:<node>) stays at the pre-seal size (e.g. 693B unchanged after a 455B sealed update applied at wal_seq 9).
3. The full-state join snapshot (encode_state_and_sv) therefore serves the pre-seal plaintext; op_set::open_new_ops finds no OPS_MAP ops (opened=0) and the joiner stores only the original fixture body, never the sealed edit.

The op-set client_id can't simply be changed — the ADR-023 fence requires derive_kb_client_id(fp, epoch).

Fix direction: on enable, transition each already-shared node to a CLEAN op-set lineage (re-seal its current content as op 0 into a fresh op-set doc that the daemon's node doc adopts), so subsequent sealed edits graft instead of colliding with the plaintext base. The JOIN-DECRYPT open-on-join logic (collab_bridge PendingResponseKind::KbJoin, landed in fix/joiner-content-sync) is correct and ready — it just needs the node to actually be a sealed op-set.

Note: the upstream approve-side bug (the owner authored the member Admit against a stale collection snapshot, tombstoning the genesis/SetEncryption op-log so the joiner couldn't even derive the key) is fixed on fix/joiner-content-sync — the joiner now derives the content key; this #171 node-lineage gap is the remaining blocker for the full 3d gate (#153).

[cuttlefisch]

Core fix landed — 3d gate (#153) is now GREEN

Fixed on fix/joiner-content-sync (commit c044c341): on E2e enable, the network task RE-SEALS every already-shared node, seeding build_kb_node_update_request with each node's CURRENT plaintext state so op 0 CONTINUES the node's client-id lineage (clock K+1) instead of colliding at clock 0. It grafts onto the daemon's plaintext node doc, later sealed edits chain onto it, and a joiner opens the sealed content on join.

• Node plaintext states are plumbed main-thread → network task via a new node_states field on CollabCommand::KbSetEncryption, gathered by the read-only Editor::kb_share_node_states.
• Also fixed a --test-runner gap (sibling of KB collab: owner editing an IMPORTED+shared node is rejected by the epoch fence (imported client_id lineage) #166): the headless runner never set editor.kb.data_dir, so a JOINing scenario kept synced/decrypted nodes in-memory only (interactive mode persists). Now set from mae_data_dir() → joined instances write through to their durable per-instance cozo store (what the disk oracle reads).

Verified end-to-end via scripts/collab-encrypted-e2e.sh: joiner DECRYPTS the sealed snapshot, daemon store/WAL/logs carry only ciphertext, owner holds plaintext, the MAE_E2E_NEGATIVE control LEAKS the canary (oracle has teeth). Deterministic across runs. Adversarial unit test added in op_set.rs.

Remaining under this issue: the PRE-enable plaintext base still sits on the key-blind daemon (it was already shared before enable). A true confidentiality purge needs transitioning the node to a FRESH lineage on the daemon (discard the plaintext doc), not just adding the op-set alongside it. Tracking that here.