What characters are you encountering that are not supported?

The private key should be stored as GitHub secret in your repository to ensure that it doesn't leak and is stored securely. I haven't had a problem pasting it in the form field there at all, even though the key contains newlines.

How are you trying to pass in the secret key?

I think there is also a question of how you get the private key file into the run on disk securely so that it can be referenced by this new option.

In my case, the secret is indeed passed as an environment variable on GitHub, but as Base64. It's a shared secret of the organisation I can't (as in "don't have permission" and "would break"). And decoding it is tricky because of special character handling (though not impossible I guess). One of the problematic character is \0.

My personal feeling regarding the API of this action is that it should take a file as input by default (since you have to create one anyway), rather than a raw string. I understand the concern regarding the deletion of the file, but then it's just the responsibility of the caller.

This sounds like a specific use case for your organization that may not apply to others.

If you're on a hosted runner, you should use GitHub repository secrets. It's a system designed for secret management but only supports environment variables.

If you're on a self-hosted runner, you should either use GitHub repository secrets or have the key already imported into GPG as part of the process of setting up the runner.

In regards to your specific use case, you're not able to do something like this as a workaround?

export FOO='VGhpcyBpcyBhIGZpbGUgd2l0aCBuZXdsaW5lcwotIGxpbmUgMQotIGxpbmUgMgotIGxpbmUgMwo='
export DECODED_FOO="$(echo -n "$FOO" | base64 --decode)"

The decoded base64 has newlines and it works fine in my terminal. I know you mentioned that set-output has encoding issues but I'm surprised that you're having the same trouble with just regular echo.

Anyways, supporting files sounds great on the surface but how those files get on disk securely and are cleaned up are a very serious concern. I'm not sure what a secure mechanism for that might be. We also don't want to encourage having plaintext private keys sitting around on disk either (we only do this very temporarily and we clean it up immediately). Sure, we can say that it's the user's responsibility. But at the same time it's the project's responsibility to prevent users from making choices that can can lead to adverse security outcomes.

If this is a widespread need and not just a workaround for one organization, the only way that I would personally be comfortable with this is if there are BOLD, in your face warnings in the README about the implications.

All that being said, I'm just a regular guy and I'm not an official maintainer on the project 😄

I just contributed the original GPG signing feature. So it's not really my call. I just want to make sure that we're thinking about these things before moving forward any further.

export FOO='VGhpcyBpcyBhIGZpbGUgd2l0aCBuZXdsaW5lcwotIGxpbmUgMQotIGxpbmUgMgotIGxpbmUgMwo='
export DECODED_FOO="$(echo -n "$FOO" | base64 --decode)"

I don't see how this can work if the key has a null character. It'll be cut as environment variables are C-strings. A potential solution is to convert from base 64 in JavaScript and directly store as a GitHub Actions output (so it'll be encoded again), which I initially did, but it felt wrong to depend on a separate action for that.

Basically it all sums up to: gpg takes a file as input, why would this wrapper do things differently? But if it does because of security reasons which I understand to some extent, then my PR should be closed. I'll let maintainers decide.