Will GitHub Actions support pull_request events from a fork to a private base repository?

Just posting back so that anyone who stumbles upon this topic has an update…

I submitted feedback on January 29th through the provided link with reference to the documentation and this topic as well as a bulleted use case and statment of how competitors offer this feature. Additionally, two explicit questions with my feedback asking if this feature is planned and if there is a public roadmap available.

It is currently February 17th - almost 3 weeks later - and I have not heard back from anyone.

If this continues, we will just have to abandon GitHub Actions as the feature is obviously not ready for a super simple and common use case of having private source code with development done on forks of that code and GitHub’s competitors provide support for this.

15 Likes

Sorry for the bad experience. I am trying to contact to the appropriate engineering team. When I get any response, I will update here at the first time. Thank you for your understanding. 

1 Like

We have had a similar experience. I also reached out via the feedback form a few weeks ago and have not heard back. We’ll probably have to evaluate other options as well, unfortunately.

2 Likes

If this continues, we will just have to abandon GitHub Actions as the feature is obviously not ready for a super simple and common use case of having private source code with development done on forks of that code and GitHub’s competitors provide support for this.

Exactly the same thing over here.

10 Likes

Once again checking back to just keep anyone coming here updated.

It has been just under a month and we have yet to receive a response; we would be accepting of something as short and simple as “we plan to support this and here is a link to the roadmap” but thus far crickets; nothing other than @yanjingzhu attempting to get the engineering team involved.

Additionally, we came across a second super simple workflow that is made unusable through GitHub Actions by this lack of support: the standard actions/labeler functionality. Can’t automagically apply labels on pull requests from a fork when the base repository is private.

While we would absolutely love to continue use of GitHub Actions, we must abandon them until this is supported or - at the very least - a roadmap showing that support is planned is provided. Again, your competitors support this for obvious reasons; why don’t you?

5 Likes

This is a feature we want to support and plan to. 

We are working with our security team to get signoff from them to allow us to enable this feature.  They have a concern that once a repo is forked the owning org no longer has control over who is added to the repo fork and therefore it opens up more doors for a malicious actor to get code into the repo that would then run in the CI that could then exflitrate code and secrets.  Given the general nature of CI I am not sure there is any real mitigation other than the trust boundry of the org and its collaborators.  

I hope to have an update on when we can schedule this work soon.

Thank you for your patience. 

13 Likes

I’m surprised why this doesn’t have more traction. Seems like a very basic/essential use-case for any repo with deployment workflows.

Possible use case:

Someone has a deployment workflow in their repo that they don’t want internal users with write access to be able to trigger/modify via a branch push. It’s quite easy to do this by simply modifying an existing workflow file to get triggered on a custom branch. The forking approach would ideally remove developer access to secrets, letting devs run linting/tests, but not deployment workflows, on their forked PRs. 

1 Like

Just so I understand.  Does this also apply to a forked repo that is not private?  We are wanting to use the same labler and when pull requests target the main repository from a forked branch.  Will we have the same problem?

1 Like

@randelldawson, this issue affects when the base repository is private and you open a pull request from a fork. If your repository is public, you should have no issue. But I do believe that if the pull request includes any changes to the workflow, it will use secrets set on the fork rather than the base. So, as far as a labeler, you should be fine.

1 Like

Thank you @chrispat. I had seen this message earlier but wanted to hold off until we had reached a final decision before replying. Unfortunately, we’ve not yet definitively decided to abandon or not; to be fair, until your response, we were going to abandon GitHub Actions, but as we can actually see some visibility into the fact that at least someone actually wants to support this, we’re currently holding off on abandonment.

We are working with our security team to get signoff from them to allow us to enable this feature.  They have a concern that once a repo is forked the owning org no longer has control over who is added to the repo fork and therefore it opens up more doors for a malicious actor to get code into the repo that would then run in the CI that could then exflitrate code and secrets.  Given the general nature of CI I am not sure there is any real mitigation other than the trust boundry of the org and its collaborators.

Right; if the repository is private, someone had to have given the forking user access to the repository; there would have to be some level of trust there. Perhaps even a simple opt-in for the owning organization/user of the base repository to allow these actions to run?

I hope to have an update on when we can schedule this work soon.

I am anxiously looking forward to hearing when this may occur. While they have only been minor so far, we have actually had a couple bugs that made their way into a couple different deployment environments whereas they would have been caught much earlier had we had the ability to have our unit tests run via GitHub Actions.

3 Likes

@kceb, you actually bring up something that we had future plans for as well that I had neglected while going through this issue. We actually would like short-lived deployments to occur for the lifetime of the open pull request on some of our projects in the future. This current limitation prevents that as well.

1 Like

Hi @chrispat. Is it practical to make PRs from forks run the actions in the target branch, rather than any changes in the PR itself? 

From a UX perspective, ideally the UI could

  1. display a clear mesage on the PR that existing action configuration was used.

  2. give the repo admins the ability to test the proposed changes to the Actions.

  3. provide the repo admins with a clear warning near the “merge button” that changes to CI config should be reviewed carefully.

@iainsmith The problem is not just CI config changes but code changes as well. 

Even with a read only token that we typically give to PRs from forks for public repos that is a significantly elevated permission in the case of a private repo.  It could enable a malicious user to exfiltrate issues, other PRs, and any other data the token can read that the malicious user who had been added to the fork would not have been able to read simply by updating a PR that had been opened back to the upstream by someone who was a collaborator on the upstream.

We are aware that other CI providers enable this workflow, but, there is no expectation in those providers that you have the ability to make authenticated GitHub api calls from within their environment as you need to be able to do with Actions.  

We are currently looking at ways the administrator of a repo can provide different sets of permissions for the token based on the scenario.

2 Likes

@chrispat,  Sounds promising. thank you very much for the update. Do you have an ETA  ? 

Does anyone at GitHub realize how bad it is that pull requests from Forks are so much limited because of read_only tokens? Basically GitHub Actions are useless on PR level for most of the GitHub projects. Event the GitHub-owned action for welcoming first-time contributor. Majority of cases is that first contribution comes from outside user, from a fork, and of course welcoming the contributor is not possible as the action cannot post a message in a PR because token is read_only.

Why there is not integration with codeowners, and flow from other CI systems is not copied. Prow CI build for Kubernetes project solves it super nice. When you create a PR and you are from outside of the organization, the CI doesn’t run, the owner fo the CI files has to make a comment to the pr /ok-to-test. So noone can exploit CI, super secure and well integrated.

3 Likes

I wrote a blog post where I complain and also propose solution, how others are solving the same security challenge https://dev.to/derberg/github-actions-when-fascination-turns-into-disappointment-4d75

Ehh sadly we have to abandon github actions until this is fixed. I can’t believe this is even released for private repositories without this basic requirement. The team wasted time to implement this only to figure out this bug afterwards.

4 Likes

@chrispat what about starting by allowing the CI run on private forks from users from the same organization? Also, the org could enable the tests with some button under the https://github.com/org/project/settings/access? Thanks to @cjschooley for pushing this issue through over the months. 

Its just so sad that nothing happens here!

Github is a great tool but without this feature github actions completely useless.

2 Likes

Can we please at least have an update/roadmap from GitHub Engineers on this feature request ?. 

Already, the first quarter of the year 2020 is over and we are still waiting for this feature request. 
This has been discussed numerous times already.

3 Likes