How to see my git secrets?

[Fl4m3Ph03n1x]

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?

[BrightRan]

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

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

github.com

TestGitHubPackagesRML/TestNpm/blob/080990526adbb61b0365e4b207d972de7d46dc77/.npmrc#L1

//npm.pkg.github.com/:_authToken=${GITHUB_TOKEN}
registry=https://npm.pkg.github.com/testgithubpackagesrml

github.com

TestGitHubPackagesRML/TestNpm/blob/080990526adbb61b0365e4b207d972de7d46dc77/package.json#L3

{
  "name": "@TestGitHubPackagesRML/testnpm",
  "version": "${PKG_VERSION}",
  "description": "This package is used to test npm for use with GitHub Packages.",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "repository": {
    "type": "git",
    "url": "git+https://github.com/TestGitHubPackagesRML/TestNpm.git"
  },
  "author": "",

github.com

TestGitHubPackagesRML/TestNpm/blob/080990526adbb61b0365e4b207d972de7d46dc77/.github/workflows/CI.yml#L27

  uses: actions/checkout@v2


- name: Setup node
  uses: actions/setup-node@v1
  with:
    node-version: 12


- name: Set package version
  run: echo "::set-env name=PKG_VERSION::${{ env.MAIN_VER }}.${{ github.run_number }}.$(date +"%y%m%d")"


- name: Publish package
  run: |
    sed -i 's/${PKG_VERSION}/${{ env.PKG_VERSION }}/g' package.json
    npm publish
  env:
    GITHUB_TOKEN: ${{secrets.GITHUB_TOKEN}}

[Fl4m3Ph03n1x]

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?

[BrightRan]

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

[kostyanius]

the most dumb solution for ci/cd that i have ever faced.

[mirdhyn]

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.

[IlmariKu]

This worked perfectly, thanks!

[lukepon]

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?)

[airtower-luna]

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.

[lukepon]

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.

[scottmelhop]

Github secrets are not really that secret, especially when combined with Github actions. You can for example have your github action create a new branch, create a new file, write your secrets, add it to the new branch, commit it and push it. Then you can navigate to that branch in the UI and the secret will be there for everyone to see. So as long as Github actions are enabled, no secret is safe.

[unfor19]

@Fl4m3Ph03n1x

To answer your question:

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

name: Recovering secrets
Assumption:
You've created the following GitHub secrets in your repository:
MY_CLIENT_SECRET - encrypt/decrypt with openssl - useful for public and public repositories
MY_OPENSSL_PASSWORD - used to protect secrets
MY_OPENSSL_ITER - Use a number of iterations on the password to derive the encryption key.
High values increase the time required to brute-force the resulting file.
This option enables the use of PBKDF2 algorithm to derive the key.
on:

push:

workflow_dispatch:
jobs:

openssl:

name: Recover With OpenSSL

runs-on: ubuntu-20.04

steps:

- uses: actions/checkout@v3

- env:

MY_CLIENT_SECRET: ${{ secrets.MY_CLIENT_SECRET }}

MY_OPENSSL_PASSWORD: ${{ secrets.MY_OPENSSL_PASSWORD }}

MY_OPENSSL_ITER: ${{ secrets.MY_OPENSSL_ITER }}

run: |

echo "MY_CLIENT_SECRET (***)     = ${MY_CLIENT_SECRET}"

echo "MY_CLIENT_SECRET (openssl) = $(echo "${MY_CLIENT_SECRET}" | openssl enc -e -aes-256-cbc -a -pbkdf2 -iter ${MY_OPENSSL_ITER} -k "${MY_OPENSSL_PASSWORD}")"

echo "Copy the above value, and then execute locally:"

echo "echo PASTE_HERE | openssl base64 -d | openssl enc -d -pbkdf2 -iter $MY_OPENSSL_ITER -aes-256-cbc -k $MY_OPENSSL_PASSWORD"

The trick is to encrypt the secret before printing it, with a known MY_OPENSSL_ITER and MY_OPENSSL_PASSWORD. That way, you can locally decrypt it; I even wrote a blog post about this specific topic as it really bothered me that it’s not possible to recover secrets once they’re set - How To Recover Secrets From GitHub Actions - DEV Community

[ClaireCJS]

It would be nice if there were some sort of comment we could insert

Much like the comments to tell pylint to stop nagging about thing sin python "# pylint: disable=W0103"

If we could put a comment like "# github: secret"

which would then cause github to replace it _in the checked out code, that would be fantastic too.

[airtower-luna]

Technically, you could use something similar to

run: sed -i "/@MY_SECRET@/$MY_SECRET/g" my_file.py
env:
  MY_SECRET: ${{ secrets.MY_SECRET }}

to search and replace any occurrence of @MY_SECRET@ in the source file.

However, I'd strongly advise against it, and against anything else that requires secrets in source files. It's too easy to make mistakes that way that reveal secrets, and annoyingly hard to change them when necessary. ⚠️

A better approach is to read secrets from a configuration file or environment variables, whatever works better for you. That way your workflow can just write/set that, and call your code without any modification.

[ClaireCJS]

Oh I totally agree, but i still believe this should be a feature. It doesn't hurt to have extra layers of protection. People make mistakes.

[airtower-luna]

I might have misunderstood what you want then. I thought you were looking for a way to insert secrets into your code files, which would remove a layer of protection. Did you mean something else? 🤔

[ClaireCJS]

I was perfectly clear, twice. I'm not repeating myself.

[tatyree]

A bit late to the party, but my solution to this problem was to set up a Firebase Cloud Function on an existing, experimental project that already had Could Functions and Firestore configured. In one of my GH Action configurations, I used HTTP Request Action from the GH Actions Marketplace to post each secret to the endpoint. I configured the function to add a new record to a temporary Firestore collection with each post. Committing the HTTP Request Action configuration was enough to get a complete record of all of my secrets. Finally, I removed the HTTP Request Action configuration from my next commit, copied the secrets out of Firestore using the web console and deleted the Firestore collection.

[gajus]

Just do:

jobs:
  debug_secrets:
    name: 'debug secrets'
    steps:
        run: echo '${{ toJSON(secrets) }}' | base64
name: '[apps] debug secrets'
on:
  pull_request:
    types:
      - opened
      - synchronize
      - reopened