JSON-type secrets are not being safely redeacted.

[retzero]

Describe the bug
A clear and concise description of what the bug is.

I have this json secrets.
And this will give readable prints which is not very secret.
Only { and } are masked.

• Registered secrets

{
  "id": 123,
  "uname": "john-doe",
  "password": "foobar"
}

• Workflow example

      - run:  echo "${{ secrets.ITEM_JSON }}"

• Output

***
  id: 123,
  uname: john-doe,
  password: foobar
***

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Run '....'
3. See error

Expected behavior
A clear and concise description of what you expected to happen.

Runner Version and Platform

Version of your runner?

• 2.278.0

OS of the machine running the runner? OSX/Windows/Linux/...

What's not working?

Please include error messages and screenshots.

Job Log Output

If applicable, include the relevant part of the job / step log output here. All sensitive information should already be masked out, but please double-check before pasting here.

Runner and Worker's Diagnostic Logs

If applicable, add relevant diagnostic log information. Logs are located in the runner's _diag folder. The runner logs are prefixed with Runner_ and the worker logs are prefixed with Worker_. Each job run correlates to a worker log. All sensitive information should already be masked out, but please double-check before pasting here.

[TingluoHuang]

According to doc:

To help ensure that GitHub redacts your secret in logs, avoid using structured data as the values of secrets. For example, avoid creating secrets that contain JSON or encoded Git blobs.

https://docs.github.com/en/actions/security-guides/encrypted-secrets#naming-your-secrets

[retzero]

Oh, I see. It's a limitation. 😢
Is there any action to take care of this topic? Or... are you just leaving it like this?

[TingluoHuang]

When we get a multi-line secret, we are going to match any given line of the secrets in your log to protect you the most.
In your example, the runner will try to find any outputs that contain:

• {
• "id": 123,
• "uname": "john-doe",
• "password": "foobar"
• }

However, when you use bash to echo the string out, it changes the output

from "password": "foobar" to password: foobar

From the runner's point of view password: foobar is not a "secret". 😢

[retzero]

Got your point!

[bryanmacfarlane]

One option is to store the base64 encoded json as a secret and then decode action side. someone could even write an action to do this

$ export test_sec=$(echo '{\nid:"123"\n}' | base64)
$ echo $test_sec
ewppZDoiMTIzIgp9Cg==
$ export test_sec_d=$(echo $test_sec | base64 --decode)
$ echo $test_sec_d
{
id:"123"
}

you would store the base64 encoded string as the secret. you would still need to take care the the decoded json isn't logged to output though.

Another option is if there's a secret portion of the json. e.g.

{
   id:"123",
   password="shhh"
}

then you can also store or register dynamically the 'shhh' part as a secret and then you're not as concerned if it gets outputted. The dynamic option is interesting if your workflow calls an api or cli JIT which returns json. If that's the case you can get the json, and register shhh as a secret via runner commands