How to see my git secrets?

Background

I had some secrets in my code and upon learning about GitHub Actions I decided to save them in the repositories secret menu for later use in my pipeline.

Problem

However, now I need to access this secrets to develop a new feature and I can’t. Every time I try to see the value it asks me to update the secrets. I dont want to update anything I just want to see their values.

Question

How can i see the unencrypted values of my secrets in the project?

@fl4m3ph03n1x,

I recommend that you should avoid trying to output the values of repository secrets in the workflow runs. This may lead to the risk that the secrets are leaked.
When you try to print secrets to the log, GitHub automatically redacts secrets printed to the log, the values of the secrets will be masked and displayed as “***”.

If you want to use the repository secrets in the source code files of your project when you build the project in the workflow runs, maybe you can try the following methods.

  1. If the source code files can recognize and access the system environment variables, you can set the secrets as environment variables on the runner machine.
    In the workflow files, you can use the 'env’ key to set the environment variables.
env:
  ENV_VAR_NAME: ${{ secrets.SECRET_NAME }}

In the source code files, use the appropriate expressions to access environment variables. The expressions may be different between different types of the files. The expressions may include “${ENV_VAR_NAME}”, “$ENV_VAR_NAME”, “$env:ENV_VAR_NAME”, etc…

  1. If the source code files can’t recognize the mapped system environment variables, you can use the command (such as ‘sed’) to directly replace the expressions in the source code files with the value of the environment variables.
    For example:
sed -i 's/${PKG_VERSION}/${{ env.PKG_VERSION }}/g' package.json

Below is a simple example that is applying both of the above two methods.



1 Like

Thank you for your response.

My app can read the secrets from environment variables and is indeed doing so. My question is more aimed at “How can I, a human being, see the secrets I saved earlier?” Is this even possible?

Let’s say I need to show someone the content of these secrets, how can I do it?

@fl4m3ph03n1x,

We have no safe way to fetch the values of secrets, and actually it is not recommended to try fetching and sharing the secrets.

while there is no safe way to display the secret, the tricky & unsafe way (if you really need to) is to run something like echo ${{secrets.SECRET_NAME}} | sed 's/./& /g' in a workflow, that would output the secret with spaces between each character, Github will not recognize the secret and will not hide it.
Beware that the secret will then be in the actions logs in clear form, and everybody having access to the repo will be able to see it.

Is there any way to avoid this? For instance if you have a serviceaccount.json in your gitaction secret and a potentially nefarious actor wants to read it? It seems that this is pretty damning of gitactions because the secrets are scoped to people who have access to the repository and not people themselves (or is that wrong?)

Then underlying assumption is basically that anyone with direct write access to the repository is trusted. After all, with that access they could put malicious things directly into the code.

Forks are a different story, see Using encrypted secrets in a workflow:

With the exception of GITHUB_TOKEN , secrets are not passed to the runner when a workflow is triggered from a forked repository.

So someone making a pull request would have to trick you into merging the secret-stealing code.

You make a good point about the write access. But injecting malicious code seems like a whole different problem, dependencies alone may cause this.
My concern is more that after setting up a pipeline for a team that somebody may think that those aws secrets or whatever; would be useful to have locally for testing or for giving to others so they can quickly change something (like injecting malicious code).
What I’ve set up now is basically an audit log to see who is accessing resources with which credentials but it would save me and mine time if the secrets could be scoped to certain teams or individuals, in line with the principle of least privilige, instead of a repository.

1 Like