[jira] [Updated] (IGNITE-28913) GitHub Actions: run fork PR checks without checking out untrusted code in a privileged context (broken by actions/checkout v4.4.0)

["Ignite TC Bot (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-28913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ignite TC Bot updated IGNITE-28913:
-----------------------------------
    Fix Version/s: 2.19

> 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
>             Fix For: 2.19
>
>          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)