[FIX] Point CI's gitleaks at the repo's .gitleaks.toml - #97
Merged
Merged
Conversation
gitleaks-action only uses a repo config when GITLEAKS_CONFIG names it. Without that it runs the built-in default ruleset and silently ignores the .gitleaks.toml at the repo root -- so every allowlist entry in that file is honoured by the local pre-commit hook and then re-flagged in CI. The file has carried an allowlist for the Privacy transaction fixture since Aug 10 without it ever taking effect here; the mismatch only surfaced now because a PR added a second entry (the JS<->Rust crypto golden vector) whose finding actually lands on a changed line. `[extend] useDefault = true` in that config keeps the full default ruleset, so this narrows nothing -- it only stops CI and the local hook from disagreeing about the same file. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Auto-merge skippedThis PR touches a path this pipeline always treats as needing a human: Review and merge manually. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bug
gitleaks-actiononly uses a repo config whenGITLEAKS_CONFIGnames it. Without that it runs gitleaks' built-in default ruleset and silently ignores the.gitleaks.tomlat the repo root.So every allowlist entry in that file is honoured by the local pre-commit hook and then re-flagged in CI. Local and CI have been disagreeing about the same file.
The config has carried the Privacy transaction fixture allowlist since Aug 10 without ever taking effect here. It only surfaced now because #94 adds a second entry (the JS↔Rust crypto golden vector) whose finding lands on a changed line, so
verifyactually fails.The fix
One env var.
[extend] useDefault = truein that config keeps the full default ruleset, so this narrows nothing — it only stops CI and the local hook from disagreeing.Verification
Locally, on the branch carrying the vector,
gitleaks detectpasses with the config and the identical finding is reported without it — which is the CI behaviour this corrects.Ordering
#94 stays red until this merges. Nothing wrong with #94's own contents; it's blocked on this.
This touches
.github/workflows/, so the sensitive-path guard will hold it for human review rather than auto-merging. Correct — a change to how secret scanning is configured is exactly what that guard is for. Worth reading closely: confirmuseDefault = truereally is still in.gitleaks.toml(it is, line 2), since that's the one thing standing between this and a much weaker scan.🤖 Generated with Claude Code