feat(federation): verify approval token before awaiting_approval → active

Receiver-side defense — closes the trust-bypass class the cheap fix
(4533e36) cannot cover. The /peer/accept handler's awaiting_approval
branch now requires an approvalToken matching the one stored on the
local peer row before promoting to active. Without a match:
- autoAccept=0 falls through to queueApprovalRequest (no bypass; new
  approval-request queued, existing awaiting_approval row untouched).
- autoAccept=1 falls back to permissive promotion (no regression vs
  prior behavior, since autoAccept=1 would accept any inbound regardless).

Successful match also deletes any stale approval-request row for the
origin to prevent debris accumulation from prior bypass attempts.

Refactor: queueing path extracted to a top-level queueApprovalRequest()
helper so both the no-existing-peer case and the awaiting_approval
mismatch fallback share one implementation. Helper generates a fresh
single-use token on every call.

Adds 'accept_awaiting_approval_fallback' variant to PeerActivationReason
to distinguish the autoAccept=1 fallback path from the verified path
in onPeerActivated audit logs.

Spec §3.5, §3.6.

Test counts: 289 → 301 (+12).

This commit is contained in:

Jannis Braun

2026-04-26 11:48:33 +02:00

parent 9e078c44ba

commit 058eb992e4

3 changed files with 493 additions and 68 deletions

									
										packages/server/src/utils/federationPeerActivation.ts
									
		+1
		
												View File
												
				@@ -9,6 +9,7 @@ export type PeerActivationReason =

				  | 'initiate_accepted'

				  | 'accept_rejected_override'

				  | 'accept_awaiting_approval'

				  | 'accept_awaiting_approval_fallback'

				  | 'accept_pending'

				  | 'accept_new'

				  | 'approval_handshake'