Is there a way to allow write access for GITHUB_TOKEN on pull_request events from forked repos?

I’m currently writing some project automation actions for https://github.com/enarx/enarx. One of the things I’d like to do is automatically label pull requests and add them to projects based on those labels.

Unfortunately, as I recently learned, the GITHUB_TOKEN made available for API actions does not get write access on pull_request events from forked repositories (which is the only workflow our project supports). I understand why this restriction is in place – if it had write access, a malicious actor could fork the repository, make nefarious changes to Actions, and wreak havoc on the base repository. However, this does cut out a very common open-source workflow from being automated.

I _did_ find a messy workaround for this: I had my action listen for check_suite events, then enlisted a third-party bot to run on every pull_request event and always pass. I had to extrapolate the PR number from the event JSON, but it _did_ work – the GITHUB_TOKEN did have write access, and my action ran as intended.

I’ll also note the above workaround does not cause any security issues since check_suite checks out the master branch of the repo – thus, any forked pull request that attempts to make nefarious changes has to actually be merged before it has any effect.

Here’s the pull request with the action in question: https://github.com/enarx/enarx/pull/360

This approach is not at all scalable, however; you end up losing all granularity of what types of events trigger actions. If I wanted to have one event trigger on the PR being assigned, and another trigger upon the PR being labeled, there’s no good way to do that.

My question, given all of that: is there any officially-supported way to accomplish write access on pull_request events from forked repos? If not, could Github consider adding an option to its pull_request event functionality to enable this workflow? The security concerns that exist are legitimate, and I’m not proposing that the existing functionality change; rather, I envision an option available for pull_request events that, like check_suite, makes the action run on a checkout of the master branch instead of a checkout of the forked branch – and, in doing so, would also enable the GITHUB_TOKEN to have write access. (It could even be a separate event, like pull_request_base.) That would not create any additional security problems, and would be a significant boost to GHA’s functionality with forked repos.

Hi @mbestavros ,

Thank you for being here and appreciate your sharing! 

At the moment, secrets are indeed limited for forks.  As you point out, the GITHUB_TOKEN variable provided to forks is read-only, and secret variables are not provided to forks at all. We may have some more advanced secrets management in the future, but we don’t have plans to give forks the ability to write to the main repository directly.

If not, could Github consider adding an option to its pull_request event functionality to enable this workflow? (It could even be a separate event, like pull_request_base.)

>> Appreciate your ideas! However according to the policy, it’s recommended to raise an ticket here where github product manager will take a review. You’ll get a response officially.

Thanks.

I just implemented a workaround for the PRs from forked repos:  a CI job (that runs in the context of the forked repo) can post some artifacts, and a cron job (runs every 5 minutes) checks the result of those recent jobs, and can do any action desired because it runs in the context of the primary repo.

https://github.com/nyurik/auto_pr_comments_from_forks

My example posts CI run results to the PR as a comment.

1 Like