mirror of
https://github.com/Such-Software/smirk-backend-core.git
synced 2026-10-17 15:31:38 +02:00
jwinterm
8120d93fb8
6 confirmed findings (review wqrd2gka3), 3 root-cause fixes: - HIGH: execute_erasure had no status recheck and the sweeper's SKIP LOCKED row lock was released before execution (separate connection), so (a) a request CANCELLED after the sweep's SELECT was still executed, and (b) a fleet could double-execute one erasure (duplicate hash-chained audit row, double count). Fixed by making execution atomically CLAIM the row as its first statement — `UPDATE ... SET status='completed' WHERE id=$1 AND status='confirmed' RETURNING user_id` — and skipping (returns false) when 0 rows match. Only the first executor of a still-confirmed request proceeds; a cancelled/already-done row is a no-op; on any later failure the whole tx (claim included) rolls back. - account-existence oracle: the absent-user request path returned a FRESH random erasure_id + advancing scheduled_for each call, while a real account returned a STABLE get-or-create id — a re-call distinguisher. The request response is now constant-shape: a STABLE id (real, or a deterministic integrity-secret-keyed synthetic for the absent path), a fixed "pending" status, and NO scheduled_for (it's meaningful only at confirm, where grace starts, and is returned there). - config: ERASURE_GRACE_PERIOD_HOURS is bounded (<= 10 years) in validate(), so the u64->i64 cast can't wrap negative (defeating grace) and Duration::hours can't panic. Dismissed after verification: ERASURE_ENABLED without FEATURE_NOSTR_IDENTITY (validate already requires PUBLIC_API_URL; the nostr_identity coupling is a nicety). Tests extended: cancelled-request-not-executed (HIGH regression), double-execute no-op. 140 lib + 140 integration green, no drift, scans clean.