fix(gate): require a Bot author type alongside the release-please branch shape

[forkwright]

The hole

github.head_ref is the branch name chosen by whoever opens the PR. Both gate workflows used it as a trust predicate, sufficient on its own:

# hybrid-gate.yml — Verify no AI attribution
case "$PR_HEAD_REF" in
  release-please--branches--*)
    exit 0          # <- no author check
    ;;
esac
if [ "$PR_AUTHOR" = "dependabot[bot]" ]; then   # <- the very next waiver DOES check the author

Anyone able to open a PR names their branch release-please--branches--x and takes the waiver on any content. The asymmetry with the dependabot waiver one line below is the tell.

Four sites, and the two files waive different things:

file	what the branch predicate alone was skipping	reach
hybrid-gate.yml:465	the AI-attribution attestation	11 repos call this
gate-attestation.yml:31	the entire "trusted automation" pass	this repo
gate-attestation.yml:53,60 (negated)	the checkout and the Gate-Passed trailer verification	this repo

The second file is the sharper one: it is not policy evasion, it is skipping the attestation that a PR's tip was actually gated — in the repo that hosts the reusable workflows the other eleven execute.

The fix

Both conditions necessary, neither sufficient. The branch pattern stays, because it is the half that is stable: release-please's login varies (github-actions[bot] under GITHUB_TOKEN, a PAT owner after kanon#1092) while its branch shape does not.

The error was treating stable and unforgeable as the same property. user.type is both — GitHub derives it from the resolved account and a pusher cannot set it.

The part worth noticing

gate-attestation.yml already carried this, as justification for env-var indirection:

head_ref is attacker-controlled text — env-var indirection keeps it out of shell interpolation

The author knew the property and drew one of its two conclusions: defended against shell injection with it, then used it as the trust predicate eleven lines above. Same fact, one consequence applied.

No effect on current releases

release-please authors as github-actions[bot], type Bot, so the waiver still fires today. When kanon#1092 moves it to a PAT-owned (human) account, user.type becomes User, the waiver stops firing, and that release PR goes red rather than silently exempt — the correct direction to fail, and a one-line allowlist addition at that point.

Verification status — read this before merging

This is unverified by execution, and I am not claiming otherwise. VERIFICATION.md requires observed pre-fix failure and observed post-fix success; what I have is a source-level argument plus valid YAML.

Both gate workflows are workflow_call-only, and this repo runs only actionlint on its own PRs — so a probe PR here never executes them and would prove nothing. The negative case has to be observed in a consuming repo, against a pinned SHA.

That is being done in aletheia: a probe PR from a release-please--branches--… branch carrying an attribution marker, observed before the pin bump (expect: waived, vulnerability live) and after (expect: caught). I will post both captures here before this merges.

Related: gnomon#51's Done when asks for exactly that — "proven by a check that goes red on that shape". This repo has no test harness at all (it is README.md plus .github/workflows/), so there is nowhere for a negative-case fixture to live permanently. Standing one up is a separate design call, and it is the difference between this fix being argued and being guarded.

Credit: found by a completion audit in a peer seat and handed over rather than patched, since this repo is mine.

[forkwright]

Pre-fix capture — vulnerability confirmed live by execution

Probe: forkwright/aletheia#6858, pinned at the pre-fix SHA of hybrid-gate.yml.

Shape: branch release-please--branches--waiver-probe, human author, no Gate-Passed trailer on the tip, attribution marker in the body.

Result — both waivers fired.

check	result	duration
hybrid-gate / ai-attribution	pass	9s
hybrid-gate / check-trailer	pass	9s

Nine seconds is not a scan. The job log carries the decisive line:

release-please--branches--*)
  echo "Release-please branch ($PR_HEAD_REF): AI attribution check exempt."
  exit 0
  ;;

So this is observed, not argued: an arbitrary author naming a branch release-please--branches--… skips the AI-attribution check and the Gate-Passed trailer verification, on any content.

The attacker population is not empty

While this probe was running, forkwright/aletheia#6854 arrived from an external account (alienvisitor8675-bit) on a bounty-fix-… branch. aletheia is public; outside parties open PRs on it today.

That PR is unrelated slop and is being closed on its merits. It matters here only for one reason: it removes the last reason to treat this waiver as theoretical. The capability to open a PR — the only capability the bypass requires — is demonstrably held by parties outside the org.

Post-fix capture

Follows once this merges and aletheia's pin is bumped. Same branch, same commit, same author; only the pinned workflow changes. Expected: both checks run, and both fail.

[forkwright]

Post-fix capture — the fix is proven by execution

Probe aletheia#6858, pin bumped to 08a0bad (this PR's merge commit). Same branch, same author, same repo; only the pinned workflow changed.

capture	pin	marker location	ai-attribution
pre-fix	54f1af7	PR body	pass — waiver fired, exit 0, nothing scanned
post-fix	08a0bad	PR body	pass — waiver refused, check ran, found nothing (marker was in the wrong place for what this check reads)
post-fix	08a0bad	commit trailer	fail — waiver refused, check ran, caught it

The decisive line from the post-fix run:

Branch release-please--branches--waiver-probe has the release-please shape
but author forkwright is type User, not Bot — not waiving.

That is the waiver declining to fire for a human author on a release-please-shaped branch, which is exactly the defect. The third row confirms the check then does its job.

One honest limit on this capture. The middle row taught me my own probe was initially mis-aimed: I put the marker in the PR body, and this check reads commits. A pass proved nothing until the marker moved into the commit. Worth recording because the mis-aimed version looked like a successful verification.

check-trailer is NOT verified by this probe. It passed in every run — but via docs_only_exemption, an independent and legitimate waiver that my probe's file types (.txt, .yml) trigger. Testing the trailer waiver needs a probe touching non-docs paths. The gate-attestation.yml sites are fixed by the same reasoning and reviewed, but they are argued, not observed, and I am not going to call them verified.

Probe closed and branch deleted.