Fix backport GitHub Action for forks

[pquentin]

Due to the way GitHub Actions works, there is no way to backport pull request from forks using the pull_request workflow trigger as it won't have write permissions on the repository. The fix is to use pull_request_target. It is much more dangerous, but is safe if those conditions are met:

• The code in the pull request can be trusted (it is, since we have merged it)
• The GitHub Action can be trusted (it is, I have audited it and pinned to a specific hash)

Does my analysis make sense?

[JoshMock]

I think it makes sense given the code is already merged when the action runs. I'm especially curious if there's historical context around not using pull_request_target on the team, or if InfoSec has concerns.

[flobernd]

Your analysis is correct 🙂

I'm especially curious if there's historical context around not using pull_request_target on the team, or if InfoSec has concerns.

The pull_request_target trigger is of limited use in a lot of cases, because instead of running against the workflow and code from the merge commit, the event runs against the workflow and code from the base of the pull request. If you explicitly use checkout on the merge commit in such workflows, you basically circumvent all the security features introduced for pull_request. In our case this would be fine as the PR is already checked and merged.

@pquentin Did you verify that backport action correctly works under these conditions? Without checking the code, it probably uses the GH API to retrieve the PRs instead of working with the commits directly, but it's probably a good idea to double check.

[pquentin]

@pquentin Did you verify that backport action correctly works under these conditions? Without checking the code, it probably uses the GH API to retrieve the PRs instead of working with the commits directly, but it's probably a good idea to double check.

Yes, backport explicitly supports forks. It does not retrieve the PRs, it runs based on the closed and labeled activity types for the pull_request_target workflow trigger (you can see them in the diff of this pull request).

Then it parses the labels sent as part of the payload (to see if a backport is needed at all and to which branch), then clones the repo, cherry-pickes the merged commit, pushes that commit, and opens the backport pull request using the GitHub API.