From 7c2ab2bb58641c5e471110243a61557e410b15a6 Mon Sep 17 00:00:00 2001 From: Paul Bezilla Date: Sun, 6 Sep 2026 10:17:00 -0600 Subject: [PATCH 1/2] Give the gitleaks job the token it needs on pull requests The action exits before scanning a pull_request event without GITHUB_TOKEN, so the job was green on push and red on every pull request. Being a required check, it blocked all three this repository has had -- among them the bump of this same action. --- .github/workflows/ci.yml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index fd7e7cb..e464de6 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -119,5 +119,13 @@ jobs: - name: gitleaks over full history uses: gitleaks/gitleaks-action@ff98106e4c7b2bc287b24eaf42907196329070c7 # v2.3.9 env: + # The action refuses to scan a pull_request event without this and + # exits before reading anything: "GITHUB_TOKEN is now required to + # scan pull requests". It passed on push, where it is not needed, + # so the job was green on main and red on every pull request. It is + # a required check, so that combination blocked all three pull + # requests this repository has had, including the one that would + # have upgraded this action. + GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} GITLEAKS_ENABLE_UPLOAD_ARTIFACT: "false" GITLEAKS_ENABLE_SUMMARY: "false" From 0c7dbd74eb864396f7e1e4e1aa93416f9bb0c3cf Mon Sep 17 00:00:00 2001 From: Paul Bezilla Date: Sun, 6 Sep 2026 10:19:43 -0600 Subject: [PATCH 2/2] Note the two things the trailer allowlist does not catch Both are deliberate and neither was written down, which is how a reduction starts reading as an oversight. A vendor name in the body of a message passes: the allowlist reads the trailer block and nothing else. That is the trade. Catching attribution by key works against any tool, including one that ships tomorrow, where a name list only ever catches what someone already thought to write down. Nothing scans the working tree either. The hand-written hooks under .git/hooks/ that used to are inert wherever they survive, because core.hooksPath makes git ignore that directory. They are not coming back: the same scan matched nothing across the full history of every repository here, and it walked build artefacts, so a full validation run could leave a clean tree unpushable. --- CONTRIBUTING.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 9526acf..91d8008 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -91,6 +91,31 @@ up last. A new evidence word — `Tested:`, `Confirmed:` — needs adding to the allowlist in both files before it can land there. That is the accepted cost of a tight list. +### What the allowlist does not catch, on purpose + +Two things pass this gate that an earlier version of it would have stopped. Both +are the deliberate reduction, not an oversight. + +**A vendor or tool name in the body of a message.** The allowlist reads the +trailer block and nothing else, so such a name written in a paragraph of prose is +ordinary text and is accepted. Attribution is stamped as a trailer, and an +unlisted key is refused whether or not the gate has heard of the tool that wrote +it — a stronger guarantee than a name list can give, because it does not need +updating when a new tool ships. Matching words in prose is a different job, and +the denylist that did it matched nothing across the full history of every +repository in this family. + +**Anything in the working tree.** Nothing greps the checkout for vendor names. +Hand-written hooks under `.git/hooks/` once did, and `core.hooksPath` makes git +ignore that directory entirely, so any that survive there are inert. They have +not been restored and should not be: it is the same scan with the same zero +matches, and it walked build artefacts, so a full validation run could leave a +clean tree unpushable. + +The same trade is taken in every repository that shares this gate. Consistency +across them is the property worth keeping — a one-repository exception would be +the defect, not the fix. + **History was not rewritten when this changed.** No force push, no retag, nothing dropped; only the rule applied to new pushes is different.