fix: laat de geheimenscan niet op de eigen reflog vallen #533

Merged

brenno merged 1 commit from fix/geheimenscan-reflog into main 2026-07-22 11:03:13 +00:00

Conversation 0 Commits 1 Files changed 2 +19

brenno commented 2026-07-22 11:03:11 +00:00

Owner

Copy link

Summary

make check-secrets failed on a clean checkout of main, on git's own bookkeeping rather than on repository content: trufflehog's filesystem pass read .git/logs/HEAD — 2109 lines of commit SHAs — and matched a 40-character hex SHA as a LokaliseToken. Both gitleaks passes reported no leaks.

Closes #522

Why this mattered more than one false positive

The gate depended on machine-local state. It went red or green depending on how many commits you happened to have made locally, so two people on the same commit got different answers and re-running fixed nothing. A gate that fails for a reason nobody can act on teaches people to skip it — and this is the last line before a committed credential reaches a public repository.

Changes

.git/ excluded in both .trufflehogignore and .gitleaks.toml, in the existing idiom of those files (each exclusion carries its reasoning inline).

The history is not affected. It stays fully covered by the separate trufflehog git and gitleaks git passes. What is excluded is .git/ as a filesystem, which contains nothing that is not also read elsewhere.

Verification, both directions

This is a security gate being narrowed, so "it is green now" proves nothing on its own:

• Clean on a fresh tree — make check-secrets exits 0, both scanners report no leaks.
• Still fires on a planted credential in lib/ — leaks found: 1, exit 2.

A note for whoever verifies this next. My first attempt used AKIAIOSFODNN7EXAMPLE / wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY and the scan passed — which looked like the gate had gone blind. It had not: that is AWS's own documentation example pair, and both scanners deliberately allowlist it. It is useless as a test fixture. A non-allowlisted key of the same shape is caught immediately.

Gates

make check green. make check-secrets now green. make sast still red for the pre-existing reason in #521 — next.

Principles

Narrows a security control, which is the direction that deserves scrutiny rather than trust. Weighed above: coverage is unchanged because the excluded path is redundant with the git passes, and the claim was tested rather than assumed.

## Summary `make check-secrets` failed on a clean checkout of `main`, on git's own bookkeeping rather than on repository content: trufflehog's filesystem pass read `.git/logs/HEAD` — 2109 lines of commit SHAs — and matched a 40-character hex SHA as a `LokaliseToken`. Both gitleaks passes reported no leaks. Closes #522 ## Why this mattered more than one false positive The gate depended on **machine-local state**. It went red or green depending on how many commits you happened to have made locally, so two people on the same commit got different answers and re-running fixed nothing. A gate that fails for a reason nobody can act on teaches people to skip it — and this is the last line before a committed credential reaches a public repository. ## Changes `.git/` excluded in both `.trufflehogignore` and `.gitleaks.toml`, in the existing idiom of those files (each exclusion carries its reasoning inline). **The history is not affected.** It stays fully covered by the separate `trufflehog git` and `gitleaks git` passes. What is excluded is `.git/` as a *filesystem*, which contains nothing that is not also read elsewhere. ## Verification, both directions This is a security gate being narrowed, so "it is green now" proves nothing on its own: - **Clean** on a fresh tree — `make check-secrets` exits 0, both scanners report no leaks. - **Still fires** on a planted credential in `lib/` — `leaks found: 1`, exit 2. **A note for whoever verifies this next.** My first attempt used `AKIAIOSFODNN7EXAMPLE` / `wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY` and the scan passed — which looked like the gate had gone blind. It had not: that is AWS's own documentation example pair, and both scanners deliberately allowlist it. It is useless as a test fixture. A non-allowlisted key of the same shape is caught immediately. ## Gates `make check` green. `make check-secrets` now green. `make sast` still red for the pre-existing reason in #521 — next. ## Principles Narrows a security control, which is the direction that deserves scrutiny rather than trust. Weighed above: coverage is unchanged because the excluded path is redundant with the git passes, and the claim was tested rather than assumed.

brenno added 1 commit 2026-07-22 11:03:11 +00:00

fix(poort): sluit gits eigen boekhouding uit van de geheimenscan ... 44d917fcba

make check-secrets stond rood op een verse main. Niet op
repository-inhoud maar op .git/logs/HEAD: tweeduizend regels commit-SHA's,
waarin een 40-teken hex-SHA als LokaliseToken wordt herkend.

Dat maakte de poort afhankelijk van machinelokale toestand. Twee mensen op
dezelfde commit kregen een ander antwoord, opnieuw draaien repareerde
niets, en de melding was niet af te handelen. Een poort die faalt om een
reden waar niemand iets mee kan, leert mensen hem over te slaan — en dit
is de laatste lijn vóór een gecommit geheim in een publieke repo.

De historie blijft volledig gedekt: die wordt door de aparte git-pas van
béide scanners gelezen. Uitgesloten is .git/ als *bestandssysteem*, waar
niets in staat dat niet ook elders staat.

Getoetst in twee richtingen: schoon op een verse boom, en `leaks found: 1`
op een geplante sleutel in lib/.

Closes #522

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

brenno merged commit 8c98f110c0 into main 2026-07-22 11:03:13 +00:00

brenno deleted branch fix/geheimenscan-reflog 2026-07-22 11:03:14 +00:00

brenno referenced this pull request from a commit 2026-07-22 11:03:14 +00:00

Merge pull request 'fix: laat de geheimenscan niet op de eigen reflog vallen' (#533) from fix/geheimenscan-reflog into main

Sign in to join this conversation.

Reviewers

No reviewers

Labels

Clear labels   

accepted

Assessed and will be built

  

bug

Something is broken

  

declined

Assessed and will not be built

  

docs

Documentation only

  

duplicate

Already tracked elsewhere

  

enhancement

New feature or improvement request

  

good first issue

Small, self-contained, and a good place to start

  

in-progress

Someone is working on this right now. Do not start it in parallel.

  

needs-info

Waiting for the reporter

  

privacy

Personal data can leak. Handled before anything else.

  

security

A weakness someone could use. Handled before anything else.

  

triage

Awaiting assessment

No labels

accepted

bug

declined

docs

duplicate

enhancement

good first issue

in-progress

needs-info

privacy

security

triage

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

1 participant

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

LibreKAT/Ocideck!533

No description provided.