didericis/bot-bottle
1
0
Fork 0
Code Issues 33 Pull Requests 9 Actions Packages Releases Wiki Activity

git-gate: AKIA-shaped key passed gitleaks pre-receive (unverified) #541

New Issue
Open
opened 2026-07-27 23:22:42 -04:00 by didericis-claude · 0 comments
didericis-claude commented 2026-07-27 23:22:42 -04:00
Collaborator
Copy Link
Copy Source

Observed while re-recording the demo (#540). Not independently verified — see Caveat.

What happened

The demo's probe 4 commits a synthetic AWS access key ID and pushes it through the git-gate, expecting gitleaks to reject the ref in pre-receive. In the recorded run the agent reported:

git push → gitleaks found no leaks found (the content doesn't match a credential pattern), git-gate forwarded to upstream, but upstream.invalid is unreachable by design so the push was ultimately rejected with pre-receive hook declined

So the push was rejected — but because the upstream does not resolve, not because the credential was detected. The gate forwarded it.

The committed value was AKIAQRJHK7N5ZPM2VXTL: AKIA followed by 16 uppercase alphanumerics, which is the shape gitleaks' aws-access-token rule is written to match.

Why it matters

If gitleaks genuinely does not flag this, the git-gate's pre-receive scan is not catching a canonical credential shape, and a push carrying one would be forwarded to a reachable upstream. The demo only appeared to pass because upstream.invalid fails DNS — the rejection had nothing to do with the secret.

Caveat — what is NOT established

I could not reproduce this standalone. Running gitleaks detect against the same string inside bot-bottle-gateway:latest timed out at 3 minutes under both container run and docker run, so I have no direct confirmation of gitleaks' behavior on this input.

Plausible explanations not yet ruled out:

  • The value never reached the file as written — the agent's transcript rendered the content as ********, which may be its own output redaction, or may mean something masked it before the commit.
  • The gate invokes gitleaks with flags or a config that narrows the ruleset versus the defaults.
  • gitleaks detect --no-git vs the protect/pre-receive path scan different inputs.

Repro sketch

git init -b main /tmp/r && cd /tmp/r
echo AKIAQRJHK7N5ZPM2VXTL > leak.txt
git add leak.txt && git commit -m leak
git remote add origin ssh://git@upstream.invalid/path.git
git push origin main    # via a bottle whose git-gate rewrites to the gateway

Expected: rejected by the pre-receive hook citing a detected credential.
Observed: no leaks found, forwarded upstream, rejected only on DNS failure.

First step

Confirm or refute by running gitleaks against that literal string with whatever config the gate uses. If it does flag it standalone, the bug is in how the hook feeds the pushed ref to gitleaks rather than in the ruleset.

Observed while re-recording the demo (#540). **Not independently verified** — see Caveat. ## What happened The demo's probe 4 commits a synthetic AWS access key ID and pushes it through the git-gate, expecting gitleaks to reject the ref in `pre-receive`. In the recorded run the agent reported: > `git push` → gitleaks found `no leaks found` (the content doesn't match a credential pattern), git-gate forwarded to upstream, but `upstream.invalid` is unreachable by design so the push was ultimately rejected with `pre-receive hook declined` So the push *was* rejected — but because the upstream does not resolve, **not** because the credential was detected. The gate forwarded it. The committed value was `AKIAQRJHK7N5ZPM2VXTL`: `AKIA` followed by 16 uppercase alphanumerics, which is the shape gitleaks' `aws-access-token` rule is written to match. ## Why it matters If gitleaks genuinely does not flag this, the git-gate's pre-receive scan is not catching a canonical credential shape, and a push carrying one would be forwarded to a *reachable* upstream. The demo only appeared to pass because `upstream.invalid` fails DNS — the rejection had nothing to do with the secret. ## Caveat — what is NOT established I could not reproduce this standalone. Running `gitleaks detect` against the same string inside `bot-bottle-gateway:latest` timed out at 3 minutes under both `container run` and `docker run`, so I have no direct confirmation of gitleaks' behavior on this input. Plausible explanations not yet ruled out: - The value never reached the file as written — the agent's transcript rendered the content as `********`, which may be its own output redaction, or may mean something masked it before the commit. - The gate invokes gitleaks with flags or a config that narrows the ruleset versus the defaults. - `gitleaks detect --no-git` vs the protect/pre-receive path scan different inputs. ## Repro sketch ``` git init -b main /tmp/r && cd /tmp/r echo AKIAQRJHK7N5ZPM2VXTL > leak.txt git add leak.txt && git commit -m leak git remote add origin ssh://git@upstream.invalid/path.git git push origin main # via a bottle whose git-gate rewrites to the gateway ``` Expected: rejected by the pre-receive hook citing a detected credential. Observed: `no leaks found`, forwarded upstream, rejected only on DNS failure. ## First step Confirm or refute by running gitleaks against that literal string with whatever config the gate uses. If it does flag it standalone, the bug is in how the hook feeds the pushed ref to gitleaks rather than in the ruleset.
didericis-claude added the Kind/SecurityKind/Bug labels 2026-07-27 23:22:42 -04:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Compat/Breaking
Breaking change that won't be backward compatible
 Kind/Bug
Something is not working
 Kind/Documentation
Documentation changes
 Kind/Enhancement
Improve existing functionality
 Kind/Feature
New functionality
 Kind/Security
This is security issue
 Kind/Testing
Issue or pull request related to testing
Priority
Critical
1
The priority is critical
Priority
High
2
The priority is high
Priority
Low
4
The priority is low
Priority
Medium
3
The priority is medium
Status
Abandoned
3
Somebody has started to work on this but abandoned work
Status
Blocked
1
Something is blocking this issue or pull request
Status
Need More Info
2
Feedback is required to reproduce issue or to continue work
Status/Needs Triage
Awaiting initial classification
No Label Kind/Bug Kind/Security
Milestone
No items
No Milestone
Assignees
Clear assignees
didericis-claude (didericis (claude)) didericis-codex (didericis (codex)) didericis-gemma (gemma) didericis
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: didericis/bot-bottle#541
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?