PLUTO-33 ·
plutoPluto: logger info-gate drops isCritical events before force-sync + prod LOG_LEVEL=1 = security-observability hole. logger.ts:83-85 early-returns (skips appEvents INSERT) for level=info when logLevel<3, BEFORE the isCritical force-sync block (:119-124, auth/authz+forceSync = must-persist). Prod LOG_LEVEL empty→parseInt=1<3, so ALL info events (incl. info-level auth/authz security signals that pluto-commons retains >=365d) are NOT persisted in prod. Two-part fix: (a) code — exempt isCritical (auth/authz/forceSync) from the info-gate so security events always persist; (b) ops — decide prod LOG_LEVEL>=3 (Elazar/Vercel env, also unlocks PLUTO-24 nav-event queryability). Found via PLUTO-24. Needs audit severity-confirm (how many live security events are info-level vs ERROR per PLUTO-25) before Elazar escalation. logger.ts = coder lane.
- Ref
PLUTO-33(#897)- Project
pluto- Status
- done
- Priority
- normal
- Type
- --priority
- Assigned
- — --type
- Created by
- wi-cli-venus
- Created
- 2026-06-10T06:39:35.670Z
- Updated
- 2026-06-10T07:18:21.521Z
- Closed
- 2026-06-10T07:18:21.521Z
Questions
No questions.
Event log
-
SEVERITY CONFIRMED by audit (independent logger.ts read), P2 holds, scope NARROWED. Mechanism verified: L85 info-gate returns null BEFORE the L119-124 isCritical force-sync; L230-231 'retained >=365d' comment is FALSE in prod (LOG_LEVEL=1). DROPPED (info): 7 logAuthz (loginRejected/denied/blocked-no-roles/domain-reject x5 + accessRequestRejectedDomainNotAllowed + accessRequestRateLimited) + 3 logAuth (login/logout) + nav breadcrumbs = auth-BOUNDARY audit trail lost (forensic gap). SAFE (error-level, persisted): auth-guard.ts enforcement (requireAuth/Role/Cap), deny-access.ts denials, securityAlerts (separate table). => 'auth audit trail not persisted', NOT 'access control broken'. FIX (one-line, coder lane): compute isCritical first then 'if(level===info && logLevel<3 && !isCritical) return null'. Ops half (LOG_LEVEL>=3) escalated to Elazar. Coder queue: after PLUTO-26, before PLUTO-22 Ph2.
-
Verified+scoped; coder one-line fix queued after PLUTO-26. Ops LOG_LEVEL decision to Elazar.
-
Reframe (audit+coder, post-push live-effect test): WI premise 'info auth/authz events actively dropped in prod' is FALSE. Prod appEvents holds 632 level=info category=auth rows up to v1.67.5/06-09 + info email/system rows — they persist, so runtime LOG_LEVEL behaves >=3 (NaN path), NOT the 1 that vercel env pull (LOG_LEVEL='') should yield. So prod OVER-persists all info, not losing security signal. 6d8c58b (isCritical hoist) is correct LATENT hardening — protects auth/authz/error/warn/forceSync IF LOG_LEVEL is ever corrected to a low int — NOT active-drop recovery. Commit msg wording is wrong but immutable. Separate Elazar decision filed: intended prod LOG_LEVEL value (env shows '' / doesn't parse clean).
-
PASS:6d8c58b live & clean (audit Vercel build+runtime check). Fix = isCritical hoist before the info verbosity gate so critical auth/authz/error/warn/forceSync events survive LOG_LEVEL filtering. NB reframed (see note): latent hardening, not active-drop recovery — prod currently over-persists all info due to LOG_LEVEL not parsing to intended int. Intended LOG_LEVEL value escalated to Elazar separately.