Unless you're good at actually maintaining your gpg keychain and need other people to access this, I really wouldn't bother with gpg. There are way better and simpler options.
direnv can support any cli secrets manager per project directory https://direnv.net/
I've dealt with enough "why did this break" situations with gpg secrets files used by capable teams that I'd never recommend that to anyone. And unless you really need the public key support (teams and deployment support), you're unlikely to gain anything better over a password manager.
Age doesn't even have a keychain. You are expected to maintain your keys manually. So yeah, you will never have a problem with the age keychain. In the same way you will never get into trouble with the law in an anarchy. Not everyone wants to have to deal with all the details themselves.
age looks really interesting, thanks. I also learned from that page that appending ".keys" to your GitHub profile URL (so https://github.com/yourusername.keys) returns a list of your SSH public keys! (Where is this documented...?)
Oh - so age would be a gpg replacement, and not a shell-secrets replacement. I guess it could work, but also I haven't had any issues with GPG yet (in my ~4 years regularly using shell-secrets).
ejson2env sounds nice. Don't like the syntax of `eval $(...)`, but it does THE thing that most don't - it encrypts the secrets at rest!
Also, I have multiple logins for some services (company account vs company's client account), so separating concerns is cool. And having the "context" name in the PS1 helps avoid issuing the wrong command on the wrong account - you can even add emojis to the name for maximum discernability.
What happens when you have multiple matching keys? What happens when your key expires? What happens when the output format changes? What happens when the key expires and it's attached to a hardware device? Gpg can fail in ways which do not tell you anything about the real underlying issue.
I promise this happens all the time to people for lots of stupid reasons.
The more general version of this is probably sops[1].
(A general problem with these kinds of “wrap GPG” tools is that you end up with “mystery meat” encryption/signatures: your tool’s security margin is at the mercy of GPG’s opaque and historically not very good defaults.)
This is 13 lines of Bash plus GPG which is available ~everywhere and a pretty lowish level Linux dependency. SOPS is +20KLOC of Go with support for cloud KMS etc etc. I think you got your mystery meat analogy backwards.
Since GPG and openssh support the TPM for some operations, I am tempted to store secrets in the TPM instead; I think a hardware safe is better than messing with persistent envars and having to pay attention to children etc.
But I am very nervous about doing so, since I have heard bad things about the reliability of the TPM (limited writes or something?) and locking myself out of important places. Any people with experience using the TPM for secrets in Linux?
I have been following the GnuPG mailing list for some years now. I must of missed that. Could we have some references to where someone has been told something to the effect of "encryption is supposed to be hard".
this in a credentials file to source before doing some operation? sure.
I usually do: ` ( . ./credentials && ./the_thing ) ` so the secrets are only in the subshell and don't linger in my shell session forever.
but don't put that in <shell>rc , as it a) will be visible for all other (child) processes of your shell b) will spawn pinentry everytime the agent's cache ttl expires
That hides it in the source, but doesn't hide it in the execution environment that can access the ENV. Everything you run inside your shell could still read it. (but if you're running untrusted things...you've already lost)
Readit News
Age has a simpler interface and SSH key support https://github.com/FiloSottile/age
ejson2env has the environment variable integration and ejson has multiple backends https://github.com/Shopify/ejson2env
direnv can support any cli secrets manager per project directory https://direnv.net/
I've dealt with enough "why did this break" situations with gpg secrets files used by capable teams that I'd never recommend that to anyone. And unless you really need the public key support (teams and deployment support), you're unlikely to gain anything better over a password manager.
https://github.com/rust-lang/rust/pull/139966
https://github.com/rust-lang/rust/pull/139966.patch
https://github.com/rust-lang/rust/pull/139966.diff
ejson2env sounds nice. Don't like the syntax of `eval $(...)`, but it does THE thing that most don't - it encrypts the secrets at rest!
Also, I have multiple logins for some services (company account vs company's client account), so separating concerns is cool. And having the "context" name in the PS1 helps avoid issuing the wrong command on the wrong account - you can even add emojis to the name for maximum discernability.
I promise this happens all the time to people for lots of stupid reasons.
(A general problem with these kinds of “wrap GPG” tools is that you end up with “mystery meat” encryption/signatures: your tool’s security margin is at the mercy of GPG’s opaque and historically not very good defaults.)
[1]: https://github.com/getsops/sops
(I also wouldn’t call GPG a low level dependency.)
Encrypting YAML files' values may be handy for another project - will take note of it.
But I am very nervous about doing so, since I have heard bad things about the reliability of the TPM (limited writes or something?) and locking myself out of important places. Any people with experience using the TPM for secrets in Linux?
My main takeaway was that GPG isn’t nearly as user friendly as it needs to be.
You'll get told off by the GPG devs with something along the lines of "encryption is supposed to be hard".
export SOME_SECRET="$(pass show some/secret)"
but don't put that in <shell>rc , as it a) will be visible for all other (child) processes of your shell b) will spawn pinentry everytime the agent's cache ttl expires