The gate could not see what it was gating
Description and use
A pre‑commit hook that verified receipts for claim‑bearing files accepted stale receipts because it only checked the first matching line in the receipts file, allowing a file to bypass review for four days. The fix compares the staged blob hash, eliminating the hole.
Problem
A pre‑commit hook that verifies receipts for claim‑bearing files accepted stale receipts because it only checked the first matching line in the receipts file, allowing a file to bypass review for four days.
Outcome
The pre‑commit guard was vulnerable to stale receipts for four days. Fixing the lookup to use the staged blob hash eliminated the hole and prevented future bypasses.
Workflow
- 1. Commit a change to a claim‑bearing file.
- 2. Pre‑commit hook runs and greps the receipts file for the file path.
- 3. Hook selects the first matching line with
head -1and accepts it without checking the blob hash. - 4. Commit succeeds, bypassing review.
- 5. After the fix, the hook greps for the exact blob hash and rejects stale receipts.
- 6. Commit fails if no matching receipt is found.
- 7. The author writes tests to cover the new logic and runs mutation testing to ensure robustness.
Evidence
I keep a pre-commit hook on my portfolio repo that refuses a commit touching a claim-bearing file unless a receipts file carries a receipt for it.
For four days, any file that had been reviewed once was exempt from review forever.
The defect line existed… line 61, the head -1 shown above
The fix reads BLOB=$(git rev-parse ":$f") and greps ":: blob $BLOB"
- Record date: 2026-10-03T15:40:45.994Z