You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
SEVERITY: DEFER-FORBIDDEN (fail-open in a security guardrail) — LIVE ON main (c52e30ad).
Triggering example
A write whose only machine path is C:\Projects\acme\... or C:\Dev\acme\....
Observed
hpp::scan_text's cheap prefilter gate at plugins/guardrails/lib/path-detection/hardcoded-path-patterns.sh:74 is grep -qE 'Users|/home/|repos' — it early-returns (no match → skip) before the detailed scan. But the detailed Windows body HPP_WIN_REPO_BODY (plugins/guardrails/lib/path-detection/machine-path-patterns.sh:51) accepts repos|Repos|projects|Projects|dev|Dev. So Projects/Dev-only content is dropped by the prefilter and never reaches the body that would flag it = fail-open in the path-detection guardrail.
Expected
Prefilter alternation widened to Users|/home/|repos|Repos|projects|Projects|dev|Dev so the guardrail actually scans content containing the newer checkout roots. This is exactly the fix that HAD landed on PR #932 as commit 9a33e665 (widen gate + a Projects-root regression test).
Root cause (fleet incident)
PR #932's landed fix (9a33e665) was dropped by a concurrent same-identity force-push (d74e5e1 -> a318b5ac), then #932 was squash-merged (c52e30ad) in the fix-dropped state while still thread-blocked. Two compounding hazards:
A thread-blocked PR carrying a known fail-open merged anyway — a merge-gate escape.
Remedy
0.9.8 fix-forward PR off main (guardrails 0.9.7 -> 0.9.8, new CHANGELOG entry newest-on-top): restore the prefilter gate + regression test (9a33e665), and fold the stale block_no_verify_enabled plugin.json description sync that also never landed.
Category: bug (security-posture) · observed vs expected: above.
Lane: merge-drive (self-observation, rule 10)
SEVERITY: DEFER-FORBIDDEN (fail-open in a security guardrail) — LIVE ON
main(c52e30ad).Triggering example
A write whose only machine path is
C:\Projects\acme\...orC:\Dev\acme\....Observed
hpp::scan_text's cheap prefilter gate atplugins/guardrails/lib/path-detection/hardcoded-path-patterns.sh:74isgrep -qE 'Users|/home/|repos'— it early-returns (no match → skip) before the detailed scan. But the detailed Windows bodyHPP_WIN_REPO_BODY(plugins/guardrails/lib/path-detection/machine-path-patterns.sh:51) acceptsrepos|Repos|projects|Projects|dev|Dev. SoProjects/Dev-only content is dropped by the prefilter and never reaches the body that would flag it = fail-open in the path-detection guardrail.Expected
Prefilter alternation widened to
Users|/home/|repos|Repos|projects|Projects|dev|Devso the guardrail actually scans content containing the newer checkout roots. This is exactly the fix that HAD landed on PR #932 as commit9a33e665(widen gate + aProjects-root regression test).Root cause (fleet incident)
PR #932's landed fix (
9a33e665) was dropped by a concurrent same-identity force-push (d74e5e1->a318b5ac), then #932 was squash-merged (c52e30ad) in the fix-dropped state while still thread-blocked. Two compounding hazards:Remedy
0.9.8 fix-forward PR off
main(guardrails0.9.7->0.9.8, new CHANGELOG entry newest-on-top): restore the prefilter gate + regression test (9a33e665), and fold the staleblock_no_verify_enabledplugin.json description sync that also never landed.Category: bug (security-posture) · observed vs expected: above.