fix(signals): align focus-manifest.ts's glob cap with group-based counting - #2448
fix(signals): align focus-manifest.ts's glob cap with group-based counting#2448JSONbored wants to merge 1 commit into
Conversation
…nting normalizeOptionalGlob (contentLane.*Glob parsing) capped raw `*` character count at 3, the same flawed model just fixed in change-guardrail.ts's globToRegExp: a `**` pair compiles to ONE backtracking-capable group, not two, so raw counting both rejected a legitimate 2-group glob like "public/**/*.json" (3 characters) in some cases and would admit some genuinely dangerous 3-single-star-group globs at the same raw count. Export change-guardrail.ts's countWildcardGroups and MAX_GLOB_WILDCARD_GROUPS and reuse them here instead of re-deriving a separate threshold, so the two glob-safety checks in this codebase share one source of truth instead of drifting. Not a live security fix — globToRegExp's own internal cap already defuses anything that slips past this parse-time check — this closes a consistency gap where some over-complex globs got an explicit parse-time warning while others silently degraded to a never-matching pattern with no warning at all.
|
Warning 🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨 ⏸️ Gittensory review result - manual review recommendedReview updated: 2026-07-02 01:45:41 UTC
⏸️ Suggested Action - Manual Review Review summary Nits — 4 non-blocking
Review context
Contributor next steps
Signal definitions
🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed 💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →. Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.
|
|
Superseded by 536e46a ("fix(content-lane): share the wildcard-safety predicate between glob parsing and compilation"), already merged into claude/pr-b-content-lane-genericity — same fix, done concurrently in another session. Closing to avoid duplicate/conflicting work. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## claude/pr-c-guardrail-redos-hardening #2448 +/- ##
========================================================================
Coverage ? 95.92%
========================================================================
Files ? 225
Lines ? 25301
Branches ? 9204
========================================================================
Hits ? 24269
Misses ? 419
Partials ? 613
🚀 New features to boost your workflow:
|
Summary
focus-manifest.ts'snormalizeOptionalGlob(parsescontentLane.entryFileGlob/providerFileGlob/artifactGlobfrom.gittensory.yml) capped raw*character count at 3 — the same flawed model change-guardrail.ts'sglobToRegExp/matchesAnyused before fix(signals): cap globToRegExp wildcard count to prevent ReDoS #2445's fix. A**pair compiles to a single.*group, not two independent wildcards, so raw character counting is wrong in both directions: it wrongly rejects a legitimate 2-group glob like"public/**/*.json"(3 raw star characters) in some cases, and would wrongly admit a genuinely dangerous 3-single-star-group glob (e.g."a-*-*-*-b") at the same raw count — exactly the class of bug fix(signals): cap globToRegExp wildcard count to prevent ReDoS #2445 fixed.globToRegExp(from fix(signals): cap globToRegExp wildcard count to prevent ReDoS #2445) already has its own internal group-based cap (MAX_GLOB_WILDCARD_GROUPS = 2) that safely short-circuits any over-complex glob to a never-matching sentinel regex regardless of what this parse-time check lets through — full defense-in-depth already exists. This closes a consistency/UX gap: today some over-complexcontentLane.*Globvalues get an explicit "too many wildcards" parse-time warning while others silently pass validation and then silently compile to a never-matching pattern at match-time with zero warning.change-guardrail.ts'scountWildcardGroups/MAX_GLOB_WILDCARD_GROUPS(both already benchmarked and battle-tested in fix(signals): cap globToRegExp wildcard count to prevent ReDoS #2445) and reuse them directly infocus-manifest.tsinstead of re-deriving a second, separately-maintained threshold — the two glob-safety checks in this codebase now share one source of truth instead of risking future drift.change-guardrail.tshas zero imports of its own (confirmed dependency-free), so this is a safe, non-circular sibling import withinsrc/signals/.Scope
type(scope): short summaryConventional Commit format.CONTRIBUTING.mdand does not reintroduce GitHub Pages, VitePress,site/, orCNAME.Validation
git diff --checknpm run actionlintnpm run typechecknpm run test:coveragelocally — the one pre-existing sub-100% line infocus-manifest.ts(MAX_FOCUS_MANIFEST_BYTESover-length content path) is untouched by this diff and unrelated; every line/branch this PR changes is coverednpm run test:workersnpm run build:mcpnpm run test:mcp-packnpm run ui:openapi:checknpm run ui:lintnpm run ui:typechecknpm run ui:buildnpm audit --audit-level=moderate"public/**/*.json"(2 groups, 3 raw characters) is now accepted, and updated the existing "too many wildcards" test's "at cap" example to the new 2-group boundarySafety
UI Evidencesection. (N/A — no UI changes.)Notes
claude/pr-c-guardrail-redos-hardening(fix(signals): cap globToRegExp wildcard count to prevent ReDoS #2445) rather thanmainbecause it importscountWildcardGroups/MAX_GLOB_WILDCARD_GROUPSfrom that PR'schange-guardrail.tschanges; rebasing ontomainonce fix(signals): cap globToRegExp wildcard count to prevent ReDoS #2445 merges is expected to be trivial (this PR only touchesfocus-manifest.tsand its test file beyond the shared import, neither touched by fix(signals): cap globToRegExp wildcard count to prevent ReDoS #2445 itself).