Repository navigation
chore(security): secret scanning skips the vendored gitleaks allowlist - #944
Conversation
The gcp-api-key rule of the vendored gitleaks v8.30.1 rule set allowlists public example keys. GitHub secret scanning flagged them as 16 'Google API Key' leaks, in third_party/gitleaks/v8.30.1/gitleaks.toml (byte-identical to upstream: sha256 e163e53b...9caf, PROVENANCE.json) and its JSON conversion mcp_server/shared/redaction_rules/gitleaks.json. Both paths are ignored.
Codex Review Summary: ✅ CompletedThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
|
Claude finished @cdeust's task in 2m 2s —— View job Review 1 of 3: done
I found no Blockers. There are three Notes, none needing action before merge: the PR body gives the wrong JSON line range (it is 821-836, not 831-846), the header comment doesn't mention that push protection is skipped too, and the Verdict: approve |
Review 1 of 3: PR #944I found no Blockers. The five reviews (code quality, security, docs accuracy, test coverage, performance) all ran on the one changed file, What I checked:
Notes, no action before merge:
The 16 open alerts still have to be closed as false positives by someone with write access. Verdict: approve |
GitHub secret scanning opened 16 « Google API Key » alerts (2026-10-21). All of them point at the allowlist of gitleaks'
gcp-api-keyrule, the public example keys the rule must ignore, in two files:third_party/gitleaks/v8.30.1/gitleaks.toml, lines 619 to 634. The file is byte-identical to upstreamconfig/gitleaks.tomlat tag v8.30.1: its sha256e163e53b…9cafmatchesPROVENANCE.json, checked on 2026-11-07.mcp_server/shared/redaction_rules/gitleaks.json, lines 831 to 846.They are not leaked secrets.
.github/secret_scanning.ymladds both paths topaths-ignore, so that every new vendored copy does not reopen them. A future version under another directory will need its own line, as the file says. The 16 open alerts must still be resolved as « false positive », by hand or through the API, by someone allowed to write them.