gitleaks false positive on documented hash in `forgejo-mcp.md` #77

New issue

Closed

opened 2026-06-17 14:41:56 +00:00 by james · 0 comments

james commented

2026-06-17 14:41:56 +00:00

Owner

gitleaks 8.30.1 flags forgejo-mcp.md line 52 under generic-api-key:

Expected SHA-256 of the key file:
`b3862b1deefa2b726ee722e0c3d5b81681ef34803d575b2a6664e7b37fd9c736`

That's the documented expected hash of the cosign public key file a contributor downloads in step 2 of the MCP setup — a verification value, not a credential. gitleaks' generic-api-key heuristic hits on the 64-hex-char literal near the word "key".

A similar pattern appears on line 69 (the image digest sha256:5223…3786 in the cosign-verify example) — same shape, same risk of being flagged on a future rule-pack update even if today's version misses it.

Scope

Add a narrow allowlist to .gitleaks.toml:
- Scope by paths to ^forgejo-mcp\.md$ so we don't blanket-exempt the rest of the repo.
- Scope by regexes to \b[a-f0-9]{64}\b so a real secret in that file (auth token, OAuth client_secret, etc.) would still be caught.
- Combine with condition = "AND" so both conditions must match before suppression.
The allowlist entry must include a description that says what is being suppressed and why it's safe — the existing convention from .gitleaks.toml's comment template.

Acceptance criteria

gitleaks detect --source . --no-git reports 0 findings against tracked files. The .next/ cache hits aren't tracked and don't matter for the CI scan.
A new secret-looking literal added to a different file is still flagged (allowlist is narrow, not blanket).
.gitleaks.toml allowlist block has the required description comment per existing convention.

Part of epic #2.

gitleaks 8.30.1 flags `forgejo-mcp.md` line 52 under `generic-api-key`: ``` Expected SHA-256 of the key file: `b3862b1deefa2b726ee722e0c3d5b81681ef34803d575b2a6664e7b37fd9c736` ``` That's the documented expected hash of the cosign public key file a contributor downloads in step 2 of the MCP setup — a verification value, not a credential. gitleaks' `generic-api-key` heuristic hits on the 64-hex-char literal near the word "key". A similar pattern appears on line 69 (the image digest `sha256:5223…3786` in the cosign-verify example) — same shape, same risk of being flagged on a future rule-pack update even if today's version misses it. ## Scope - Add a narrow allowlist to `.gitleaks.toml`: - Scope by `paths` to `^forgejo-mcp\.md$` so we don't blanket-exempt the rest of the repo. - Scope by `regexes` to `\b[a-f0-9]{64}\b` so a real secret in that file (auth token, OAuth client_secret, etc.) would still be caught. - Combine with `condition = "AND"` so both conditions must match before suppression. - The allowlist entry must include a description that says *what* is being suppressed and *why it's safe* — the existing convention from `.gitleaks.toml`'s comment template. ## Acceptance criteria - [ ] `gitleaks detect --source . --no-git` reports 0 findings against tracked files. The `.next/` cache hits aren't tracked and don't matter for the CI scan. - [ ] A new secret-looking literal added to a different file is still flagged (allowlist is narrow, not blanket). - [ ] `.gitleaks.toml` allowlist block has the required description comment per existing convention. Part of epic #2.

james added the

area:ci

label

2026-06-17 14:42:02 +00:00

james referenced this issue from a commit

2026-06-17 15:00:01 +00:00

build(security): allowlist documented hashes in forgejo-mcp.md (#77)

james referenced this issue from a pull request that will close it,

2026-06-17 15:00:54 +00:00

build(security): allowlist documented hashes in forgejo-mcp.md (#77) #78

james closed this issue

2026-06-17 15:02:48 +00:00