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.
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.
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.
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.
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?
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.
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.
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?
@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.
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.
@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.
@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.
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.
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.
@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.