audit(federation): verify no parallel hmac-wipe-on-401 paths
Task 11 due-diligence audit for #19. Checked all signed-fetch sites in packages/server/src for 4xx-branch mutations of federationPeers.hmacSecret or federationPeers.status: - sendCallRelay (federationOutbox.ts): on 4xx returns post_failed; on 5xx/network returns peer_transient_failure. No peer-state mutation. - sendTypingRelay (federationOutbox.ts): delegates to sendCallRelay with peeringTimeoutMs:0 (fire-and-forget). No peer-state mutation. - cleanupExpiredApprovalRequests (storageJanitor.ts): sends denial, only deletes peerApprovalRequests row on success. No federationPeers mutation. - DELETE /identity (users.ts): per-origin cleanup; only deletes local userFederationRegistry on success, never touches federationPeers. - denyApprovalRequest (federation.ts): requires 2xx from remote before inserting/updating a rejected peer row. Admin-driven, not wipe. - POST /peers/:id/rotate (federation.ts): mutates pendingHmacSecret only on 2xx; returns 502 on 4xx without state change. - Auto-rotation in federationWorker.ts: same 2xx-gated pattern as manual rotate. - Unreachable-recovery health check: only promotes to active on 2xx. - ensurePeered/performHandshake (federationPeering.ts): on 403 with PEERING_REQUIRES_APPROVAL sets status='rejected' (explicit, not a HMAC-mismatch wipe); on other 4xx/5xx only deletes the row if it was a freshly created placeholder (existingPeerId falsy). Pre-existing peers are untouched. Only federationWorker.ts:269 mutates HMAC-related state in response to 401/403, and that path was rewritten in Task 5 to use evaluateAuthFailure and transition to needs_attention. No additional handlers require the bounded-retry refactor.
This commit is contained in:
Jannis Braun