Make secrets available to builds of forks

I’d rather have it as a semi-private, out-of-sight setting than in clear, plaintext in the Git repo itself, which would be included package distributions.

Thats great to hear and it  will solve our  issue which I raised earlier.  Is there any update and it will be great If you can let us know when you are planning to deploy this feature. 

Thanks in Advance… 

I’ve forked a project, because the old project is stale.  I’ve added my own secrets in settings of the new/forked project.  They’re not being passed into the build.

The only workarounds I’ve found are either:

* delete the repo, and create it again, but that deletes all metadata like issues, wiki etc

* write to support to remove the “forkage” link, which I did w/o reply

Any other ways to address it?

2 Likes

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.

1 Like

Will there be a way to create trusted actions? Actions can be in other repositories and version locked and therefore marked as “trusted”. This is similar in concept to a Github Application being trusted since you installed it and gave it specific permissions.

Jenkins does this with “shared libraries” where normal Jenkinsfiles run in a sandboxed environment and the libraries are in a trusted context and are not limited by the sandbox.

Trusted actions could access secrets. The execution of these actions could not be altered by PRs from forks, but the base repo could still enforce checks and have integrations with 3rd party services like Cypress dashboard, Codecov, etc.

Would this be an okay compromise? If Codecov or Cypress created an action that defined secrets it needed access to, we’d opt into trusting those actions and giving them access to certain secrets. That access shouldn’t matter if the PR is from the base repo or from a fork.

steps:
  - uses: cypress-io/cypress-run-action@v1
    withSecret:
      record-key: CYPRESS_RECORD_KEY

All execution is in the action with an opt-in for key sharing. If the action is only run against the base branch, compromise is limited to someone gaining malicious access to the action - mitigated by version locks (although tags could be compromised as well). Orgs could further limit compromise by only using their own actions (this example is simply a wrapper around npm run cypress:run -- --record --key=$CYPRESS_RECORD_KEY inside its own docker container with the current workspace mounted.

6 Likes

How about adding a way to “trust” Pull Request (or users) from forked repo by LGTM/Approve/or another new way?

I understand it’s unsafe to run GitHub Actions with a secret for PR from fork by default, but some actions need secret variables like codecov example or actions using GitHub Check API.

If the repository owner can approve PR (or users) to run actions with a secret, and then triggers the actions, it becomes safe to run actions.

If we want to be completely on the safe side, maybe GitHub can invalidate the “trust” if PR authors modified the code after approval. (But it’s too strict in my opinion).

It could be a bit off-topic, but I wish at least GITHUB_TOKEN has write permission for PR from fork after approving PR because many actions use GITHUB_TOKEN to use Check API or Comment API and it’s unusable on PR from fork right now.

15 Likes

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.

4 Likes

@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:

  1. Only provide the secret to the fork using the target branch’s actions.

  2. Only provide the secret to the fork if the workflow is unmodified from the target branch.

1 Like

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

4 Likes

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

1 Like

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 }}

https://github.com/python-pillow/Pillow/blob/ef4a0b2f4c9346db37140f102e80068abc280167/.github/workflows/test.yml#L94-L103

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

1 Like

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.

2 Likes

any update on this feature request?. 
Our usage of Actions came to a halt too because of many limitations for PR from forks. 

6 Likes

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: 

https://github.community/t5/GitHub-Actions/Feature-Request-Make-GITHUB-TOKEN-support-OpenID/m-p/48036#M7041

1 Like

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.

18 Likes

> codecov.io being probably the most obvious, …

Good news, you can now upload coverage to Codecov without a token:

https://community.codecov.io/t/whitelist-github-action-servers-to-upload-without-a-token/491/17?u=hugovk

1 Like

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.

2 Likes

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