[
https://issues.apache.org/jira/browse/IGNITE-28913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-28913.
---------------------------------------
Resolution: Fixed
[~zstan], thanks for your review!
> GitHub Actions: run fork PR checks without checking out untrusted code in a
> privileged context (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: 0.5h
> 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 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
> — neither workflow checks out untrusted PR code under a privileged token any
> more:
> - 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 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 (recorded in a comment
> in the file).
> - check-protected-classes.yml -> no checkout at all. This job needs
> issues/pull-requests/checks: write to comment on and label the PR, so it
> stays on pull_request_target. Instead of checking out the fork and running
> git, it now reads the PR diff through the GitHub API as data (pulls.listFiles
> + repos.getContent at the appropriate revision) inside github-script. The
> fork's code never lands on the runner, so there is nothing to opt into and
> nothing to execute. Detection logic is preserved exactly (added -> head
> revision, deleted/modified -> base, renames expanded to delete+add, @Order =
> protected class) and was cross-checked against the previous git diff/git show
> logic on real PRs (PR #13095: both report the same 92 @Order files; PRs with
> no protected changes report none). Fork-controlled file names are rendered as
> inert inline code so they cannot inject markdown/@mentions into the bot's
> comment, and the existing comment is located by a stable hidden marker
> instead of a substring match.
> Result: no workflow checks out untrusted fork code in a privileged context.
> Covering conflicting PRs without executing untrusted code under a privileged
> token would require a pull_request build + workflow_run split, which is out
> of scope here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
