Help
cancel
Showing results for 
Search instead for 
Did you mean: 
Pilot Lvl 1
Message 1 of 29

Make secrets available to builds of forks

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


image.png

 

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:

 

image.png

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!

28 Replies
Highlighted
GitHub Staff
Message 2 of 29

Re: Make secrets available to builds of forks

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

Highlighted
Pilot Lvl 1
Message 3 of 29

Re: Make secrets available to builds of forks

Good to hear!

Someone (prematurely?) marked this as solved. Is it implemented yet? Thanks!
Highlighted
Copilot Lvl 2
Message 4 of 29

Re: Make secrets available to builds of forks

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.

Highlighted
GitHub Staff
Message 5 of 29

Re: Make secrets available to builds of forks

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.

Highlighted
Pilot Lvl 1
Message 6 of 29

Re: Make secrets available to builds of forks

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.
Highlighted
Copilot Lvl 3
Message 7 of 29

Re: Make secrets available to builds of forks

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.

Highlighted
Copilot Lvl 3
Message 8 of 29

Re: Make secrets available to builds of forks

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.

Highlighted
Pilot Lvl 1
Message 9 of 29

Re: Make secrets available to builds of forks

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?

Highlighted
Copilot Lvl 3
Message 10 of 29

Re: Make secrets available to builds of forks

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.