I had a similar idea: Only provide secrets to the workflow if the workflow is unmodified.
The difference would be in the behavior of PRs from forks that modify the action. In one case, the wrong code is run. In the other case, the normal code is run but without secrets.
Either would be a decent solution. I suggest that this not be the default behavior. Put a checkbox next to each secret and let users choose if the secret is available to forks or not.
@dantup is correct. If you make a secret available to forks, it’s easy for the fork to just print your secret to the screen. That’s why you must either:
Only provide the secret to the fork using the target branch’s actions.
Only provide the secret to the fork if the workflow is unmodified from the target branch.
@ethomson wrote:
I’m sorry if I was unclear: there are no plans to deploy this feature, there are only plans to investigate whether it makes sense to add or not. As others have pointed out, it has very little utility as it only obscures secrets in an easy to overcome mechanism. As a result, we’re focusing on higher priority issues at the moment.
It has more utility than this. Obviously it’s true that if you have a repo that anyone can fork, and you supply secrets to pull requests from any of those forks, then your secrets are trivially obtainable by the forks. Others here are suggesting that security-through-obscurity is better than nothing and I do not agree with that contention.
But of course, that’s only true of “a repo that anyone can fork”! Those of us who use a central-repo-with-forks model for private repositories should be able to provision some or all private forks to access secrets in actions. This is a workflow that GitHub facilitates and even encourages, and one that’s popular among the paying users who use private repositories. The use cases abound. Let’s say I have a secret that contains the API key for my issue tracking system, and I want to move a story to an in-progress state when a developer on my team opens a pull request from their fork to the central repo. Maybe I have a secret for the webhook URL of our chat system, and I’d like pull requests from forks to the central repo to send a notification to that chat system to prompt code review. These feel like a great use cases for GitHub Actions, and I would happily provision the central repo to share secrets with the forks to accomplish them.
@haya14busa That adds a lot of complexity to the github actions. Also, they wouldn’t run until approved, so there would be a lot of waiting around on each iteration of a PR. The UI of PRs would get complex, too. You’d need a way to indicate approval per-PR and figure out if that means for all commits or only the latest. Also, people can write PRs such that others can commit to them. So if you made the approval for all future commits and then someone that you didn’t trust added a commit, they could steal the secret.
I propose a simple solution: Make it possible to designate secrets as usuable by PR forks but only when the workflow is unmodified. The UI change is to have the secrets list include a checkbox “usable by PRs”, default false. When checked, the secret is delivered to PRs that don’t modify the workflow at all. Unchecked behaves as before. Workflows that modify the PR don’t get any secrets like usual. That secret could contain a Personal Access Token that is limited to just what the user decides, like only status updates or whatever.
We temporarily worked around this for Pillow (https://github.com/python-pillow/Pillow/pull/4266) by adding a “Prepare coverage token” step before the “Upload coverage” step:
- name: Prepare coverage token
if: success() && github.repository == 'python-pillow/Pillow'
run: cp .github/codecov-upstream.yml .codecov.yml
- name: Upload coverage
if: success()
uses: codecov/codecov-action@v1
with:
token: ${{ secrets.CODECOV_TOKEN }}
name: ${{ matrix.os }} Python ${{ matrix.python-version }}
.github/codecov-upstream.yml is the same as .codecov.yml, except it has the hardcoded upstream token for Codecov.
If you do want GHA coverage from your own fork’s builds sent to your own fork’s Codecov, fetch your token from https://codecov.io/gh/my-username/repo/settings and add it as CODECOV_TOKEN at https://github.com/my-username/repo/settings/secrets.
EDIT: I was mistaken, the actual issue for us is Actions not running on PRs from forked repos, https://github.community/t5/GitHub-Actions/Github-Workflow-not-running-from-pull-request-from-forked/m-p/48146#M7089
This isn’t a particularly helpful comment but our potential usage of Actions came to a screeching halt without this feature. We build apps against Salesforce which requires all sorts of different secrets since the build is actually interfacing heavily with remote servers and applications that require auth secrets.
There was mention of running the workflow in the main repository and this seems like an ideal scenario. Perhaps it’s just a little option in the config.yml that could be set.
any update on this feature request?.
Our usage of Actions came to a halt too because of many limitations for PR from forks.
Can we un-mark this as solved, since there is clearly a lot of need for some kind of solution?
I’d suggest making the GITHUB_TOKEN support OpenID so it can be used to authenticate access to external resources. I cut a separate request for that in case it gets lost in the noise here:
It really seems like this issue is not being given high enough priority. This is especially blocking for open-source community projects.
I know many companies are using GitHub with private repos for commercial teams, and in that scenario it often makes sense for them to work on a single repository. However, I always considered the user forks + pull request workflow to be the “pure” way to do development, as it treats all contributors the same, whether they be maintainers or from the community. This is how my team at Canonical work on all our projects.
It makes sense for any number of PR checks to need secrets - codecov.io being probably the most obvious, but also any number of other potential services like percy.io. For anyone at all working in the “pure” fork+PR workflow, this means PR checks with GitHub Actions are basically useless. And this would be especially true for large community projects, which should be the lifeblood of GitHub.
For this reason, I really think this is a very central issue for GitHub Actions. Not providing a way for any meaningful checks to work on PRs from forks harms specifically large, community, open source projects, and they are, as I say, the lifeblood of GitHub.
I think there are a number of feasible ways to get Actions with secrets working on PRs from forks:
Check if the user has write access to the parent project (meaning they have access to secrets), and if so allow access to the secrets
Run checks against the parent project with all the secrets as long as they haven’t changed (and make sure to provide clear feedback if an Action has been modified and so isn’t run or isn’t provided with secrets)
Allow an approval mechanism, whereby you can grant permission to certain forks to access central secrets
This is an important issue, which will block a very many people from fully adopting GitHub Actions, including our team, until it’s fixed.
> codecov.io being probably the most obvious, …
Good news, you can now upload coverage to Codecov without a token:
I have another simple to implement (I think) idea:
New field in https://developer.github.com/v3/orgs/#get-an-organization, https://developer.github.com/v3/repos/#get-a-repository or any other place in api.
New field will contain constant value (some hash), which can be used to protect public data.
This new parameters will be available to user which have write permission and for GITHUB_TOKEN for GHA build in master repo and in fork repo.
So thanks to this anybody can easy create semisecret variable.
Ah great! That helps a lot. Thanks.
A potential solution that could work is if the secret were pulled from the fork’s secret repository, rather than the central one.
I created a separate proposal with this solution: https://github.community/t5/GitHub-Actions/Allow-secrets-to-be-shared-with-forks-from-trusted-Actions/td-p/34278
I think that it can be a little step that helps without to be a “feature”.
Use the fork secrets as a fallback.
So, if the Workflow can’t access the target secrets it can use the fork’s secrets. so the original owner can share some secrets with his trusted forks.
I don’t really need the secret to be available on a fork, but I think it could help if some actions can be defined as being “meta”. So that they can run on the current repo, instead of on the fork.
Some actions don’t need the source, so meta actions could help there.
For example, I thought I could use https://github.com/samspills/assign-pr-to-author to assign pull-requests to the person that opened the PR. Unfortunately, this doesn’t work. It only works for pull-requests within the same repo. As soon as someone forks and opens a PR, it stops working.
And those are exactly the type of pull-requests that benefit from such an action.
@smeijer This is a very nice idea. It would be great if we could have Workflows that always run on the base branch context of a PR instead of on the PR’s branch.
Hey, @ethomson. I think there are a bunch of questions, issues and requests about this such as https://github.com/codecov/codecov-action/issues/29. I wouldn’t treat this as a little of utility either.
If this cannot be resolved, it virtually means the GitHub Actions that needs a token (to label, create status checks, etc) cannot be used in most of open source projects where the contributors don’t have the write access to the upstream repository.
Run checks against the parent project with all the secrets as long as they haven’t changed (and make sure to provide clear feedback if an Action has been modified and so isn’t run or isn’t provided with secrets)
I really like this idea, but I see an issue with this. Please feel free to correct me if I’m wrong:
GitHub Secrets are generally injected in the form of environment variables, and if an attacker wants those secrets, they can still access them without changing the workflow at all.
It can be argued that the secrets can be scoped in steps – only injecting in the ones which don’t run user controlled code. This might solve problem of using Percy/codecov.io/other third-party GitHub Actions, but custom automation scripts still wouldn’t work (a problem, I suppose, many can live with). But, even then the onus of “protecting” these secrets would still be on the maintainer.
Would it be possible to mark secrets that can be shared to fork build or make some action trusted?
In our case we would like to send a mail to new contributors with some questioner, so we found an action for sending mail, but as expected it requires an SMTP user/pass…
Any suggestion for this case? Thx :]