From 45c7d7e219183bf0dfa260ca857794bcb327b0ea Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 1 Aug 2026 21:06:19 +0000 Subject: [PATCH] fix(ci): allowlist lockfile sha256 hashes in gitleaks working-tree scan The default gitleaks square-access-token rule flags the high-entropy SHA-256 package-integrity digests in uv.lock (e.g. line 5129, the parso sdist hash) as a leaked credential. Because the working-tree gitleaks job scans uv.lock on every branch, this false positive fails the scan on essentially every open PR, blocking the green gate repo-wide. Add a line-scoped regex allowlist for `hash = "sha256:"` digests so lockfile integrity hashes are no longer treated as secrets, while any genuine token elsewhere in a lockfile is still scanned. Verified with gitleaks 8.18.4 (the version CI installs): the scan goes from "leaks found: 1" to "no leaks found" (exit 1 -> 0). Co-Authored-By: Claude Opus 4.8 (1M context) Claude-Session: https://claude.ai/code/session_01L1YVe2AKQxtpn5LKpJW6BE --- .gitleaks.toml | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/.gitleaks.toml b/.gitleaks.toml index 1d91e9d8e..a05a3ec40 100644 --- a/.gitleaks.toml +++ b/.gitleaks.toml @@ -5,7 +5,17 @@ useDefault = true [allowlist] -description = "Paths excluded from secret scanning" +description = "Paths and false-positive patterns excluded from secret scanning" +# Package lockfiles (uv.lock, package-lock.json, etc.) record public SHA-256 +# package-integrity hashes. Their high entropy trips the default +# square-access-token rule (e.g. uv.lock:5129, the `parso` sdist hash), even +# though a `sha256:` integrity digest is not a credential. Match on the +# whole line so only genuine `hash = "sha256:..."` digests are allowlisted; +# any real token elsewhere in a lockfile is still scanned. +regexTarget = "line" +regexes = [ + '''hash = "sha256:[0-9a-f]{64}"''', +] paths = [ # Vendored saved web pages from Google (AI Studio / APIs Explorer): contain # Google's own public page keys, not EventRelay credentials.