Make secrets available to builds of forks

Azure Pipelines has a way to make secrets available to builds of forks:

A token is needed to upload coverage to Codecov. It’s especially important to get coverage for PRs from forks, and this a suitable workaround (“Please note that this token can leak despite being a “secret” variable. A malicious user can open a PR and send it anywhere they want. However, the token is worthless for anything except uploading coverage and it’s easy to see when someone does it.”)

GitHub Actions has no way to make secrets available to forks:

Please could you make the AP option available on GHA, or provide some other way?

At the moment the GitHub Actions workaround is to include the token in plaintext in the workflow.

Thank you!

33 Likes

This is a good suggestion, we’ll take a look.  Thanks!

8 Likes

Good to hear!

Someone (prematurely?) marked this as solved. Is it implemented yet? Thanks!

2 Likes

Another cool setting would be to always run actions from the master branch. We were using an action to label pull requests and this setting would make it work again.

3 Likes

Perhaps an option on a workflow in the PR trigger to always run the version of the workflow in the target branch instead of the PR branch.  That would enable you to have some PR workflows always run on “safe” code and not limit you to master if your workflow needs other options.

8 Likes

Is it possible to tell us when you have plan to deploy this feature?

Of course we should have option to mark each secret variable separately, I want to take decision be myself which secret variable can be pass to PR.

1 Like

This might be risky: Imagine the action, even if from the target branch, runs a shell script contained in the repo. The this script might be modified. Since you cannot tell which code from the repo will be run (maybe even a xUnit Test has been tampered with), you simply cannot trust code from PRs.

This is a must-have for organizations using private repos and forks. 

5 Likes

Out of interest, what’s the point of having a secret that is available to PRs versus not having it as a secret? It seems like anything exposed this way need to be considered public (sinc eit’s trivial for people to extract), so why not use it in plaintext?

2 Likes

When we use some value as public in code we don’t have any knowledge who has read this value.

I agree, that is easy to discover value, but to do it somebody must create pull request and do something strenge in code. So we have logs/history if somebody tryed to read value.

For example I want to use such feature to store tokens for sonar, i will have token for user who only can run analysis on public projects, so it is not critical for me if somebody stole this value. But from other side I don’t want show this in public text without control who read it.

2 Likes

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.

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

3 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