Repository navigation
fix(scripts): git-secrets DSN detectors never fire on a real connection string under -w #328
Description
scripts/setup-git-secrets.sh registers three connection-string detectors whose shape is roughly scheme://[^@]+@.
git-secrets scans with git grep -nwHEI, and -w requires the match to end on a word boundary. [^@]+@ always ends at the @, and the next character is the first letter of the hostname, which is a word character. There is no boundary there, so the match is rejected.
Measured: a staged file containing a realistic connection string with an embedded password scans clean (exit 0). Only format strings fire, because they end in a placeholder rather than a hostname letter.
So these detectors match placeholder text and miss the actual thing they exist to catch.
Fix shape
Consume the host so the match ends on a boundary:
[^@]+@[^/[:space:]]+
Worth re-measuring the whole tree after changing it, since consuming the host widens what the pattern can hit.
Found while measuring for LeanerCloud/cloud-commitments-cli#1972. Deliberately not fixed there to keep that PR's blast radius to the allowlist.
Activity
cristim commentedon Sep 8, 2026
Related observation from LeanerCloud/cloud-commitments-cli#2083's review, same
-wroot cause, worth recording here rather than as a separate issue.git-secrets scans with
git grep -nwHEI, and-wrequires a word boundary on both sides of the match. So a key glued between word characters is not caught at all:scans clean, because the key is preceded by a letter and the Azure detector's match is followed by one. Verified this is not an allowlist effect: it still exits 0 with
.gitalloweddeleted entirely, and a barexAKIA0123456789ABCDEF x-shaped line behaves the same.That is a broader consequence of
-wthan this issue's title suggests. This issue covers detectors that never fire because the match cannot end on a boundary; the case above is a key that never fires because it cannot start on one. A fix that only consumes the host, as suggested above, closes the first but not the second.Anything that concatenates a credential into a longer token, a URL built by string concatenation, a base64 blob, an environment-variable assignment with no separator, is invisible to every one of these detectors. Worth deciding whether
-wis the right flag at all, rather than patching individual patterns around it.