[
https://issues.apache.org/jira/browse/IGNITE-28913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-28913:
--------------------------------------
Description:
Since actions/checkout v4.4.0 (released 2026-07-20), a backport of the v7.0.0
"pwn request" protection announced in the GitHub Changelog on 2026-06-18,
actions/checkout refuses by default to check out fork PR code in workflows
triggered by pull_request_target (and workflow_run). The floating v4 tag was
moved onto this backport, so pinning actions/checkout@v4 picked it up
automatically. The step fails with:
Refusing to check out fork pull request code from a 'pull_request_target'
workflow. ... To opt in ... set 'allow-unsafe-pr-checkout: true' on the
actions/checkout step.
As a result, every fork PR fails at the checkout step in two workflows that
intentionally use pull_request_target (so the checks also run for PRs that
conflict with the base branch):
- .github/workflows/commit-check.yml — all 5 jobs (Check java code on JDK 17,
Check .NET code, Check ducktape on codestyle/py38/py39). First failure: run
29756250450, 2026-07-20 15:40 UTC.
- .github/workflows/check-protected-classes.yml — the Rolling Upgrade check.
Timeline note: the pull_request_target trigger for commit-check.yml (introduced
in IGNITE-28827) worked fine for fork PRs for ~7 days; the breakage was
triggered solely by the actions/checkout v4 re-release on 2026-07-20, not by
the trigger change.
Fix: add `allow-unsafe-pr-checkout: true` to each actions/checkout step that
checks out the PR head SHA. This is safe here per
https://gh.io/securely-using-pull_request_target: commit-check.yml already
restricts the token to `permissions: contents: read` with no secrets exposed,
and check-protected-classes.yml never executes the fork code (it only inspects
it as data via git diff/show/grep). The flag only acknowledges a risk that is
already consciously accepted and documented in the workflows, restoring the
pre-backport behavior.
was:
Since the GitHub Actions runner image update (~2026-07-14), actions/checkout
refuses to check out fork PR code in a pull_request_target workflow by default
(the new "pwn request" guard) and fails with:
Refusing to check out fork pull request code from a 'pull_request_target'
workflow. ... To opt in, review the risks at
https://gh.io/securely-using-pull_request_target and set
'allow-unsafe-pr-checkout: true' on the actions/checkout step.
As a result every job of commit-check.yml (Code Style, Abandoned Tests,
Javadocs; .NET; ducktape) fails on the checkout step for every fork pull
request — i.e. for all contributor PRs.
commit-check.yml uses pull_request_target deliberately (the in-file comment: so
the checks also run when the PR conflicts with the base branch) and is already
hardened for it: the workflow declares "permissions: contents: read" and
documents that no secrets may be added. The untrusted-code risk the new guard
protects against is therefore already consciously mitigated.
Fix: add "allow-unsafe-pr-checkout: true" to each actions/checkout step that
checks out github.event.pull_request.head.sha, acknowledging the documented
trade-off. (The alternative — switching the trigger to pull_request — would
lose the ability to check conflicting PRs, which the workflow explicitly wants.)
> GitHub Actions: fork PR checkout refused in pull_request_target workflows
> after actions/checkout v4.4.0 backport
> ----------------------------------------------------------------------------------------------------------------
>
> Key: IGNITE-28913
> URL: https://issues.apache.org/jira/browse/IGNITE-28913
> Project: Ignite
> Issue Type: Task
> Reporter: Anton Vinogradov
> Assignee: Anton Vinogradov
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since actions/checkout v4.4.0 (released 2026-07-20), a backport of the v7.0.0
> "pwn request" protection announced in the GitHub Changelog on 2026-06-18,
> actions/checkout refuses by default to check out fork PR code in workflows
> triggered by pull_request_target (and workflow_run). The floating v4 tag was
> moved onto this backport, so pinning actions/checkout@v4 picked it up
> automatically. The step fails with:
> Refusing to check out fork pull request code from a 'pull_request_target'
> workflow. ... To opt in ... set 'allow-unsafe-pr-checkout: true' on the
> actions/checkout step.
> As a result, every fork PR fails at the checkout step in two workflows that
> intentionally use pull_request_target (so the checks also run for PRs that
> conflict with the base branch):
> - .github/workflows/commit-check.yml — all 5 jobs (Check java code on JDK
> 17, Check .NET code, Check ducktape on codestyle/py38/py39). First failure:
> run 29756250450, 2026-07-20 15:40 UTC.
> - .github/workflows/check-protected-classes.yml — the Rolling Upgrade check.
> Timeline note: the pull_request_target trigger for commit-check.yml
> (introduced in IGNITE-28827) worked fine for fork PRs for ~7 days; the
> breakage was triggered solely by the actions/checkout v4 re-release on
> 2026-07-20, not by the trigger change.
> Fix: add `allow-unsafe-pr-checkout: true` to each actions/checkout step that
> checks out the PR head SHA. This is safe here per
> https://gh.io/securely-using-pull_request_target: commit-check.yml already
> restricts the token to `permissions: contents: read` with no secrets exposed,
> and check-protected-classes.yml never executes the fork code (it only
> inspects it as data via git diff/show/grep). The flag only acknowledges a
> risk that is already consciously accepted and documented in the workflows,
> restoring the pre-backport behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
