Found during v0.8.1 release review (Chaos Gremlin / security auditor). Pre-existing, not regressed by v0.8.1.
verifyEnvelope (verdict.ts:~196) is only called in tests — no consumer (gate decision / replay audit) actually verifies the HMAC before trusting a verdict envelope, so signing is currently produce-only (proves who-produced, not who-can-reject). Also: (1) it uses plain === string compare on the HMAC instead of crypto.timingSafeEqual; (2) when ALTIMATE_REVIEW_SIGNING_KEY is unset it falls back to an unkeyed sha256: digest that still 'verifies' — an envelope can be silently re-forged if the key is absent.
Fix: wire verifyEnvelope into the consuming/gate path; use timingSafeEqual over equal-length buffers; reject when the stored signature is the unkeyed sha256: form while a key is configured. Deferred because it needs its own design + review (signing-soundness change), not a patch-release rush.
Found during v0.8.1 release review (Chaos Gremlin / security auditor). Pre-existing, not regressed by v0.8.1.
verifyEnvelope(verdict.ts:~196) is only called in tests — no consumer (gate decision / replay audit) actually verifies the HMAC before trusting a verdict envelope, so signing is currently produce-only (proves who-produced, not who-can-reject). Also: (1) it uses plain===string compare on the HMAC instead ofcrypto.timingSafeEqual; (2) whenALTIMATE_REVIEW_SIGNING_KEYis unset it falls back to an unkeyedsha256:digest that still 'verifies' — an envelope can be silently re-forged if the key is absent.Fix: wire verifyEnvelope into the consuming/gate path; use timingSafeEqual over equal-length buffers; reject when the stored signature is the unkeyed
sha256:form while a key is configured. Deferred because it needs its own design + review (signing-soundness change), not a patch-release rush.