fix(pairing): roster verification, identity adoption, and a refusal that protects existing vaults

[th3-br41n]

Three security fixes in the pairing/roster path, landed together because they are one thread: what a roster row is worth, and what adopting an identity actually transfers. Closes the 10.3c gate's LOW plus F-492 and F-493.

1. Roster signatures are verified on the read path (LAN-2b)

verifyAddDeviceRecord existed from the start but only vault-validate called it, so the consumers that decide access trusted whatever the properties doc held. 10.3c changed what that is worth: a forged row used to buy LAN admission; now it buys every entity DEK in the vault.

listActive verifies under this vault's identity key and drops what fails. The key is a required parameter, not an option — which immediately paid for itself: tsc surfaced a third consumer grep had missed, the LAN admission roster at index.ts, handing the raw store to the handshake.

list() stays unverified so Settings can still show a bad row to remove it.

2. Joining a vault that already holds your work is refused (F-493)

Adopting an identity is an authority transfer. authorizesWrapInstall's first rule:

if (keyBytesEqual(input.senderKey, input.selfPub)) return true;

Any frame whose sender equals this vault's own sovereign key may install or rotate a DEK on any entity, bypassing the Owner check. So re-pointing a populated vault would hand the other device unconditional rotation authority over content it was never a member of — and rotation is worse than read, because the victim then emits under a key the attacker holds. The realistic path there is a user talked into scanning a hostile pairing code.

Classification is by provenance, not type: SYSTEM_ENTITY_TYPES states it is presentation-only and must "never change query or filtering semantics", so it is the wrong input for a refusal. Bootstrap principals are a closed set; an unrecognised one counts as user content, so a future seeder that forgets to register makes pairing refuse rather than silently permit.

3. The identity is actually adopted (F-492)

vault.json is updated alongside the keystore — they must name the same identity or the next open throws, which is the bug that left a joined device unable to open its vault at all. Safe only because (2) runs first: that field is the vault's tamper-evidence for key substitution, and it is now rewritten only once the pristine check has proven there is nothing behind it to protect.

Then the vault re-opens so the session is rebuilt around the adopted identity atomically. A hot swap would leave the old key in some components and the new one in others, inside an authorization path. Deliberately after paired(): a re-open failure costs a restart, never an un-paired device holding a half-adopted key.

Consent surface

The confirm step now names the identity being adopted, by fingerprint. The SAS proves the channel is not relayed; it says nothing about whose identity is on the far end — which is the thing actually being consented to.

Not closed

revokedAt is outside the signed payload, so revocation state stays forgeable by anyone who can already write the vault. That belongs with LAN-2b(d) rotate-on-revoke, which is an owner decision, and is recorded rather than bolted on.

Verification

typecheck:packages clean · lint clean (all 8 ratchets) · 1103 tests green across pairing/, collab/, sync/, storage/.

New tests pin: a fresh install is pristine; one user note is not; an unknown principal fails closed; the refusal happens before the identity secret is written; the re-open fires on confirm and not on scan; a re-open failure still leaves the device paired.

One fixture had to change — sibling-wrap-fanout.test.ts planted sig: "test-signature", precisely the forged-row shape now rejected, so it had been asserting fan-out against a roster the owner never vouched for.

🤖 Generated with Claude Code