[jira] [Updated] (IGNITE-28913) GitHub Actions: run commit checks under pull_request (not pull_request_target), broken by actions/checkout v4.4.0

["Anton Vinogradov (Jira)" <ji...@apache.org>]

     [ 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 from the GitHub Changelog on 2026-06-18), actions/checkout refuses by default to check out fork PR code under pull_request_target. The floating v4/v6 tags were moved onto this backport, so actions/checkout@v4/@v6 picked it up automatically. Every fork PR now fails at the checkout step in commit-check.yml (all 5 jobs) and check-protected-classes.yml.

Fix, following https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target, splitting the two workflows by whether they execute the fork's code:

  - commit-check.yml -> move back to pull_request. These jobs check out and execute untrusted PR code (mvn/tox/dotnet) but need no secrets and no write token, so they do not need the privileged pull_request_target context. On pull_request the fork code runs with an unprivileged, fork-scoped GITHUB_TOKEN and the checkout protection does not apply, so no opt-in flag is needed. This reverts the trigger change of IGNITE-28827; the deliberate cost is that PRs conflicting with the base branch are no longer checked. persist-credentials: false is kept on the checkouts as hygiene.

  - check-protected-classes.yml -> keep pull_request_target and set allow-unsafe-pr-checkout: true. This job needs issues/pull-requests/checks: write to comment on and label fork PRs, so it cannot move to pull_request, but it never executes the fork code (only inspects it via git diff/show/grep plus trusted github-script) — exactly the case where the guide permits opt-in. persist-credentials: false added as well.

Note: covering conflicting PRs without executing untrusted code under the privileged token would require a pull_request build + workflow_run split; that is out of scope here.

  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. 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.


> GitHub Actions: run commit checks under pull_request (not pull_request_target), broken by actions/checkout v4.4.0
> -----------------------------------------------------------------------------------------------------------------
>
>                 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 from the GitHub Changelog on 2026-06-18), actions/checkout refuses by default to check out fork PR code under pull_request_target. The floating v4/v6 tags were moved onto this backport, so actions/checkout@v4/@v6 picked it up automatically. Every fork PR now fails at the checkout step in commit-check.yml (all 5 jobs) and check-protected-classes.yml.
> Fix, following https://docs.github.com/en/actions/reference/security/securely-using-pull_request_target, splitting the two workflows by whether they execute the fork's code:
>   - commit-check.yml -> move back to pull_request. These jobs check out and execute untrusted PR code (mvn/tox/dotnet) but need no secrets and no write token, so they do not need the privileged pull_request_target context. On pull_request the fork code runs with an unprivileged, fork-scoped GITHUB_TOKEN and the checkout protection does not apply, so no opt-in flag is needed. This reverts the trigger change of IGNITE-28827; the deliberate cost is that PRs conflicting with the base branch are no longer checked. persist-credentials: false is kept on the checkouts as hygiene.
>   - check-protected-classes.yml -> keep pull_request_target and set allow-unsafe-pr-checkout: true. This job needs issues/pull-requests/checks: write to comment on and label fork PRs, so it cannot move to pull_request, but it never executes the fork code (only inspects it via git diff/show/grep plus trusted github-script) — exactly the case where the guide permits opt-in. persist-credentials: false added as well.
> Note: covering conflicting PRs without executing untrusted code under the privileged token would require a pull_request build + workflow_run split; that is out of scope here.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)