chore(security): add gitleaks allowlist after a clean full-history secret audit - #907
Merged
iamtoruk merged 2 commits intoAug 10, 2026
Merged
Conversation
A full-history secret scan (all refs, 1352 commits) plus trufflehog --only-verified came back clean: zero live secrets. gitleaks' default generic-api-key rule flags 8 non-secrets - obviously-fake test fixtures (sk-live-0123..., sk-live-AKIA...SECRETKEY), the public Claude Code and Codex OAuth client IDs (PKCE public-client flow, no client_secret), and a dedup-key string. This encodes exactly those as allowlisted so scans stay green and a real leak can never hide under recurring false positives.
…WT fixture Gitleaks ORs an allowlist entry's conditions by default, so pairing a fixture regex with a tests/ path allowlisted every finding under tests/, regex or not - a real secret committed to a test file would have been suppressed. condition = AND restores the intended semantics (verified: a planted AWS/Stripe-shaped canary in tests/ is flagged again), and the canonical example JWT header fixture that the path condition was silently covering gets its own scoped entry. Full-history scan stays green.
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
2 participants
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.
Ran a full-history secret-leak audit tonight (all refs, 1352 commits / 19.5 MB), three independent ways.
Result: clean. No real secret is leaked.
--only-verified: 0 live secrets across all history.security.ts,AppStore.swift,UpdateChecker.swift). Correct and defensive.client_secretanywhere in tracked files; OAuth is PKCE public-client, so the client IDs present are public by design. No tracked.env/.pem/.key/credentials file.sk-live-0123...,sk-live-AKIA...SECRETKEY), a dedup-key string (synth-retain-89d), and the public Claude Code / Codex OAuth client IDs.This PR
A
.gitleaks.tomlthat allowlists exactly those audited-safe cases, so future scans stay green and a genuine leak is never buried under recurring noise. Verified:gitleaks git --log-opts="--all"with this config reports no leaks found across all 1352 commits, while the default config reported 8. Nothing here suppresses a live credential - each allowlist entry is a specific known-safe string or a test-path-scoped fixture pattern, commented with why it is safe.Adding this also makes the existing
semgrepcheck's security posture legible: secret scanning now has a documented, audited baseline.