Repository navigation
fix(pr-pipeline): start the main-run review only from pr-require-checks.yml by path (hardening deferred) #10912
Description
Problem
.github/workflows/pr-review-main.yml starts on workflow_run of pr-require-checks and matches that workflow by its name. A pull request's head can add a workflow with the same name:. Its runs then start main-run review runs, and each one spends review model legs.
These runs cannot bind a forged verdict. The binder requires a run of pr-review-main.yml on the default branch, and the reviewed head comes from the gate step's own reads. So the cost is spend only. The independent security review of #10743 rated it P5.
Proposed fix
In the trigger gate step, check the triggering run's path (github.event.workflow_run.path) equals .github/workflows/pr-require-checks.yml, and its head_repository is this repository where that applies. Skip the review otherwise, before any model leg runs.
Acceptance criteria
- A
workflow_runfrom a workflow namedpr-require-checksat any other path starts no review leg. - The real
pr-require-checks.ymlcompletion still starts the review.
Refs: #10743
Activity
github-actions commentedon Oct 29, 2026
Proposed work class: work-class: scoped
Basis: automated intake triage; the lanes App applied this class.
Size: Small
Complexity: Low
Uncertainty: Known
Flags: none
Blocked by: none
Understood: pr-review-main.yml matches the triggering workflow by name only, so a PR head can add a same-named workflow and start main-run review legs that spend model budget. The issue proposes gating on
workflow_run.path(and head repository) in the trigger gate step. The report says it cannot bind a forged verdict, so this is a low-severity spend issue and gets ordinary triage. The acceptance criteria are clear. I found no likely duplicates.Automated triage, applied by the lanes App.
melodic-automation-lanes commentedon Oct 29, 2026
Not admitted to the issue lane: a criterion names .github/workflows/pr-require-checks.yml, which the issue lane cannot push (patch-protected-path); a builder session takes it. Admission takes the issue once each of those is met, when intake triages it again (
.github/actions/resolve-config/admission-rules.json).melodic-automation-lanes commentedon Oct 29, 2026
The latest triage verdict holds nothing: admission moved the issue to
status: confirmed; its comment says why.[-]fix(pr-pipeline): start the main-run review only from pr-require-checks.yml by path[/-][+]fix(pr-pipeline): start the main-run review only from pr-require-checks.yml by path (hardening deferred)[/+]kyle-sexton commentedon Oct 30, 2026
Decision recorded. Hardening deferred, closed as not planned under owner standing direction §10: "Phase: maximum throughput until open issues and open PRs both reach 0. Hardening (re-adding holds, pins, reviews) is deferred to after that, as configuration edits."
This issue adds a hold, a pin or a check that guards against our own actors, and none of its gaps can leak a token or secret, compromise the owner accounts or bill. §10 counts only those as a §3 boundary. Secret-leak scanning (gitleaks) stays on, as do both review lanes and ci-status (owner Q15).
Reopen trigger: open issues = 0 and open PRs = 0. The hardening pass finds this with
is:issue is:closed reason:"not planned" in:title "hardening deferred".kyle-sexton commentedon Oct 31, 2026
Reopening into the After zero milestone. Remaining value: trigger by path, so model legs are not spent needlessly. Closed as deferred; the owner rule of 2026-10-31 keeps work with value open and cordoned.