[Bug] make check-secrets fails on the local reflog, not on repository content #522

New issue

Closed

opened 2026-07-22 10:12:22 +00:00 by brenno · 0 comments

brenno commented

2026-07-22 10:12:22 +00:00

Owner

Describe the bug

make check-secrets fails on a clean checkout of main, on a finding inside
git's own bookkeeping:

Detector Type: LokaliseToken
File: .git/logs/HEAD

Both gitleaks passes report "no leaks found". Only the trufflehog filesystem
pass fails, and it fails on the reflog: .git/logs/HEAD is 2109 lines of commit
SHAs, and a 40-character hex SHA matches the LokaliseToken pattern.

Why this matters more than one false positive

The finding is not about repository content at all. .git/logs/HEAD is
machine-local, untracked, and never pushed — it records what this checkout did
locally. Consequences:

The gate depends on local machine state. It goes red or green depending on how
many commits you happen to have made, so two developers on the same commit get
different answers, and re-running "fixes" nothing.
It cannot be triaged away by hand the way .gitleaks.toml handles gitleaks
findings, because trufflehog is not reading that config.
A gate that fails for a reason nobody can act on trains people to skip it —
and this one is the last line before a committed credential reaches a public
repository.

Proposed solution

Exclude .git/ from the trufflehog filesystem pass. The git history is
already covered by the separate trufflehog git pass and by gitleaks git, so
nothing is lost: scanning .git/ as a filesystem re-reads the same objects in a
form that carries no useful context and generates exactly this class of noise.

Keep the two-scanner setup — the point of running both is that they disagree
usefully — and keep --no-verification (turning it off sends candidate keys to
the issuing service to see whether they are live).

Verify in two directions

Clean on a fresh checkout and still failing on a planted test credential in a
tracked file. A secret-scanning gate that has been quietly narrowed until it
always passes is worse than no gate.

**Describe the bug** `make check-secrets` fails on a clean checkout of `main`, on a finding inside git's own bookkeeping: ``` Detector Type: LokaliseToken File: .git/logs/HEAD ``` Both gitleaks passes report "no leaks found". Only the trufflehog *filesystem* pass fails, and it fails on the reflog: `.git/logs/HEAD` is 2109 lines of commit SHAs, and a 40-character hex SHA matches the LokaliseToken pattern. **Why this matters more than one false positive** The finding is not about repository content at all. `.git/logs/HEAD` is machine-local, untracked, and never pushed — it records what *this* checkout did locally. Consequences: - The gate depends on local machine state. It goes red or green depending on how many commits you happen to have made, so two developers on the same commit get different answers, and re-running "fixes" nothing. - It cannot be triaged away by hand the way `.gitleaks.toml` handles gitleaks findings, because trufflehog is not reading that config. - A gate that fails for a reason nobody can act on trains people to skip it — and this one is the last line before a committed credential reaches a public repository. **Proposed solution** Exclude `.git/` from the trufflehog *filesystem* pass. The git *history* is already covered by the separate `trufflehog git` pass and by `gitleaks git`, so nothing is lost: scanning `.git/` as a filesystem re-reads the same objects in a form that carries no useful context and generates exactly this class of noise. Keep the two-scanner setup — the point of running both is that they disagree usefully — and keep `--no-verification` (turning it off sends candidate keys to the issuing service to see whether they are live). **Verify in two directions** Clean on a fresh checkout *and* still failing on a planted test credential in a tracked file. A secret-scanning gate that has been quietly narrowed until it always passes is worse than no gate.

brenno added the

bug

triage

labels

2026-07-22 10:12:22 +00:00

brenno referenced this issue

2026-07-22 10:12:46 +00:00

fix: stuur kwetsbaarheidsmeldingen naar het adres dat we zelf documenteren #523

brenno referenced this issue

2026-07-22 10:17:17 +00:00

docs: PR-sjabloon wijst naar de bron van waarheid en vraagt naar de afweging #524

brenno referenced this issue