Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dealing safely with (multiline) secrets #107

Open
dionysius opened this issue Jan 15, 2023 · 0 comments
Open

dealing safely with (multiline) secrets #107

dionysius opened this issue Jan 15, 2023 · 0 comments

Comments

@dionysius
Copy link

dionysius commented Jan 15, 2023

I wanted to pass a gpg private key to the action but I cannot do that safely. I'm kinda addressing two issues: multiline strings and secrets.

A pgp private key looks like this:

-----BEGIN PGP PRIVATE KEY BLOCK-----

xxxx
xxxx
xxxx
...
-----END PGP PRIVATE KEY BLOCK-----

The only way to pass variables (and secrets) to the action is using the env property:

          env: |
            someenv: "${{ env.someenv }}"
            somesecret: "${{ secrets.somesecret }}"

But this way will lead to the yaml error Multi-line double-quoted string needs to be sufficiently indented. It wouldn't matter if I do somesecret: |, since the indention is still wrong.

I'm also not allowed to manipulate the secret as it would make the secret possibly visible in the workflow, since it has been altered and the log detection cannot redact it anymore.
See https://docs.github.com/en/github-ae@latest/actions/security-guides/security-hardening-for-github-actions#using-secrets):

To help prevent accidental disclosure, GitHub AE uses a mechanism that attempts to redact any secrets that appear in run logs. This redaction looks for exact matches of any configured secrets, as well as common encodings of the values, such as Base64.

I could make use of the base64 feature (accidentally a feature of gha) or maybe write a file beforehand and mount it (unsure safeness). But if anyone is not careful secrets could be exposed.

Addressing issues:

  • requiring the env property to be a yaml document is difficult to work with multiline strings. I'd rather see this to be a map
  • requesting separate property map for secrets to be handled and passed to the container accordingly careful

Would be excellent if this is addressed for v3, since I'm proposing here usage changes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant