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

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

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

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": "",

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

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?

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.

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.

@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