Skip to content

fix(scripts): git-secrets DSN detectors never fire on a real connection string under -w #328

Description

@cristim

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

  1. cristim commented on Sep 8, 2026

    @cristim
    MemberAuthor

    Related observation from LeanerCloud/cloud-commitments-cli#2083's review, same -w root cause, worth recording here rather than as a separate issue.

    git-secrets scans with git grep -nwHEI, and -w requires a word boundary on both sides of the match. So a key glued between word characters is not caught at all:

    git secrets --add 'DefaultEndpointsProtocol=httpsAKIA0123456789ABCDEF'
    

    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 .gitallowed deleted entirely, and a bare xAKIA0123456789ABCDEF x-shaped line behaves the same.

    That is a broader consequence of -w than 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 -w is the right flag at all, rather than patching individual patterns around it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions