[
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. The floating v4/v6 tags were moved onto this
backport, so actions/checkout@v4/@v6 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
(IGNITE-28827) had 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 — re-enable the fork checkout and, since that flag knowingly re-opens
execution of untrusted PR code in a privileged context, harden the workflows at
the same time (per https://gh.io/securely-using-pull_request_target):
1. allow-unsafe-pr-checkout: true on each actions/checkout step that checks
out the PR head SHA.
2. persist-credentials: false on those same checkouts, so GITHUB_TOKEN is not
written into .git/config where fork build code (mvn/tox/dotnet) could read it.
Matters most for check-protected-classes.yml, whose token has
issues/pull-requests/checks: write.
3. permissions: contents: read on sonar-branch.yml. This push-on-master job
restores a shared Maven/Sonar cache that a pull_request_target fork run can
write into (default-branch cache scope) and then runs ./mvnw install; dropping
the token from write-all to read-only bounds the blast radius of a poisoned
cache. Sonar authenticates via SONARCLOUD_TOKEN, so analysis is unaffected.
commit-check.yml already restricts the token to contents: read with no secrets
exposed, and check-protected-classes.yml never executes the fork code (only
inspects it via git diff/show/grep), so the hardening closes the remaining
abuse paths of a re-enabled fork checkout.
was:
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.
> GitHub Actions: restore fork PR checks under pull_request_target (broken by
> actions/checkout v4.4.0) and harden them
> --------------------------------------------------------------------------------------------------------------------
>
> 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. The floating v4/v6 tags were moved onto
> this backport, so actions/checkout@v4/@v6 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
> (IGNITE-28827) had 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 — re-enable the fork checkout and, since that flag knowingly re-opens
> execution of untrusted PR code in a privileged context, harden the workflows
> at the same time (per https://gh.io/securely-using-pull_request_target):
> 1. allow-unsafe-pr-checkout: true on each actions/checkout step that checks
> out the PR head SHA.
> 2. persist-credentials: false on those same checkouts, so GITHUB_TOKEN is
> not written into .git/config where fork build code (mvn/tox/dotnet) could
> read it. Matters most for check-protected-classes.yml, whose token has
> issues/pull-requests/checks: write.
> 3. permissions: contents: read on sonar-branch.yml. This push-on-master job
> restores a shared Maven/Sonar cache that a pull_request_target fork run can
> write into (default-branch cache scope) and then runs ./mvnw install;
> dropping the token from write-all to read-only bounds the blast radius of a
> poisoned cache. Sonar authenticates via SONARCLOUD_TOKEN, so analysis is
> unaffected.
> commit-check.yml already restricts the token to contents: read with no
> secrets exposed, and check-protected-classes.yml never executes the fork code
> (only inspects it via git diff/show/grep), so the hardening closes the
> remaining abuse paths of a re-enabled fork checkout.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
