[
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 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.
was:
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.
> 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: 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 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)
