Summary
The gitleaks (working tree) job fails on every pull request, regardless of its diff. The finding is a false positive in uv.lock that no PR introduced and no PR can remove.
uv records each artifact as a PyPI download URL whose path embeds the artifact's own content hash. For parso 0.8.7 that hex segment is long enough and high-enough entropy to match gitleaks' default square-access-token rule.
Evidence
Reproduced locally with the same gitleaks version the workflow pins (8.18.4), on a clean checkout:
$ gitleaks detect --no-git --config .gitleaks.toml --redact --verbose --exit-code 1
RuleID: square-access-token
Entropy: 3.884400
File: uv.lock
Line: 5129
Fingerprint: uv.lock:square-access-token:5129
WRN leaks found: 1
Line 5129 is the parso sdist entry, whose URL path segment 30/4b/90c937815137d43ce71ba043cd3566221e9df6b9c805f24b5d138c9d40a7 is a public integrity digest published by PyPI.
Observed red on PRs #1154 and #1155; uv.lock appears in neither diff.
Why this matters
secret-scan.yml runs --exit-code 1, so the job is a hard failure. Every PR carries a red secret-scan check unrelated to its contents. That trains reviewers to ignore the one check whose entire purpose is to be believed — the next finding, real or not, looks identical to this one.
Suggested fix
Suppress the benign pattern without un-scanning the file. A blanket paths exclusion for uv.lock would also hide a private index URL that embeds credentials inline (https://user:token@pypi.internal/...), which is exactly what this job exists to catch.
A line-targeted allowlist anchored on the public PyPI CDN host keeps the rest of the lockfile scanned:
[allowlist]
regexTarget = "line"
regexes = [
'''https://files\.pythonhosted\.org/packages/''',
]
Verification should show both halves: the CDN line suppressed, and the same secret on a non-PyPI host still reported.
Scope note
Configuration and test only. No dependency, workflow-logic, or application change.
Summary
The
gitleaks (working tree)job fails on every pull request, regardless of its diff. The finding is a false positive inuv.lockthat no PR introduced and no PR can remove.uvrecords each artifact as a PyPI download URL whose path embeds the artifact's own content hash. Forparso 0.8.7that hex segment is long enough and high-enough entropy to match gitleaks' defaultsquare-access-tokenrule.Evidence
Reproduced locally with the same gitleaks version the workflow pins (8.18.4), on a clean checkout:
Line 5129 is the
parsosdist entry, whose URL path segment30/4b/90c937815137d43ce71ba043cd3566221e9df6b9c805f24b5d138c9d40a7is a public integrity digest published by PyPI.Observed red on PRs #1154 and #1155;
uv.lockappears in neither diff.Why this matters
secret-scan.ymlruns--exit-code 1, so the job is a hard failure. Every PR carries a red secret-scan check unrelated to its contents. That trains reviewers to ignore the one check whose entire purpose is to be believed — the next finding, real or not, looks identical to this one.Suggested fix
Suppress the benign pattern without un-scanning the file. A blanket
pathsexclusion foruv.lockwould also hide a private index URL that embeds credentials inline (https://user:token@pypi.internal/...), which is exactly what this job exists to catch.A line-targeted allowlist anchored on the public PyPI CDN host keeps the rest of the lockfile scanned:
Verification should show both halves: the CDN line suppressed, and the same secret on a non-PyPI host still reported.
Scope note
Configuration and test only. No dependency, workflow-logic, or application change.