4 Commits
Author SHA1 Message Date
bmottin e59e26890e chore(gitleaks): allowlist Claude Code daemon roster + per-session keys
`make scan-secrets` flagged 4 generic-api-key hits in ~/.claude, all written
by Claude Code itself: roster.json's rendezvousSock/ptySock unix-socket paths
and sessionId UUID (long, high-entropy, not credentials), and two per-worker
session keys (0600). Same class as the ide/*.lock entry above — machine-local,
ephemeral, and unreachable from a commit: link.sh exposes exactly seven repo
symlinks under ~/.claude and neither daemon/ nor sessions/ is among them, so
`git ls-files` can never see them.

Left unfixed they would redden every sweep, which is the failure mode the
.env entry already argues against — a permanently red scan stops being read.

Scoped to the two exact filenames rather than the directories, and verified:
fake secrets planted beside them in the same dirs are still caught, and the
repo's own history stays clean (745 commits, no leaks).
2026-09-15 22:01:50 -04:00
Bastien Chanot 20b90465d8 chore(audit): untrack gitleaks reports; allowlist triaged FP classes
Reports are gitignored (.gitignore:94) but were swept into 17bdd08 —
even redacted they map secret types/locations for anyone with repo
access. Allowlists from the 2026-07-14 cso triage (75 findings → 0,
each class verified empirically): bare 40-hex git SHAs, gitflow-test
synthetic AWS fixture, presigned-URL key ids, expired GitHub image
JWTs, doc placeholders, IDE lock files, two prose literals. Converted
deprecated [allowlist] to [[allowlists]] (gitleaks 8.30 refuses the
mix). Makefile hint no longer suggests committing the reports.
Transcripts/file-history deliberately NOT path-allowlisted (BDR-057).
2026-07-14 18:07:11 +02:00
Bastien Chanot c4bee6aad3 chore(seo-data): install/make/doctor wiring + gitleaks allowlist for token store 2026-07-10 02:10:31 +02:00
Bastien Chanot 17bdd08b43 job7 step C: gitleaks backstop — .gitleaks.toml, pre-commit hook, make scan-secrets
Pre-commit (lib/gitflow.sh emit-hook) now runs `gitleaks git --staged` right
after the root-commit/merge-in-progress guard, on ANY branch — not gated by
branch protection, since secrets shouldn't land anywhere. Non-blocking if
gitleaks isn't installed (warn + pass). gitleaks 8.30.1: `protect` isn't
listed in --help anymore (still runs, but undocumented) — used the
documented `git --staged` equivalent instead.

.gitleaks.toml allowlists the 3 false-positive classes from the job7 triage
(marketplace.json 40-hex "sha" fields, superpowers ws-protocol.test.js nonce,
git-game test-secret-* fixtures) plus a 4th entry for ~/.claude/.env itself —
not a false positive, but scanning our own canonical vault (BDR-026) is pure
noise for a tool meant to catch stray copies. All 4 verified empirically
against the real flagged files/values before being added, not assumed from
gitleaks' docs.

`make scan-secrets` scans this repo's git history + ~/.claude (dir scan),
redacted JSON to .audit/ (verified: --redact scrubs Match/Secret in the
report itself, not just console logs — safe to commit). Repo: 0 findings.
~/.claude: 18 remaining across 8 files — 5 match the known job7 triage
(pending the GO-gated purge in step D), 3 are new discoveries outside the
original triage scope (flagged for the user, not characterized further —
never read a flagged file's content past what gitleaks' redacted report
gives you).

lib/gitflow-test.sh T16: fake secret on a feature branch (not main/develop)
→ blocked, proving the check isn't gated by branch protection; clean commit
passes; PATH without gitleaks → warns and still commits. 96/96 green.
2026-07-07 12:47:06 +02:00