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.
upofadown 4 hours ago [-]
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.
mgarciaisaia 10 hours ago [-]
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.
theteapot 12 hours ago [-]
The tool is just pulling one encryption key from your local GPG keyring. What's to maintain?
viraptor 11 hours ago [-]
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.
theteapot 10 hours ago [-]
> What happens when you have multiple matching keys?
Use keyid instead.
> What happens when your key expires?
GPG will refuse to use it for encryption. Create a new encryption key.
> What happens when the output format changes?
N/A here (?)
> What happens when the key expires and it's attached to a hardware device?
You got me.
XorNot 9 hours ago [-]
Also.. expired keys aren't unusable. The encryption doesn't stop working.
If you have an expired GPG private key it will still decrypt things encrypted with the public key.
viraptor 3 hours ago [-]
They're not unusable, but depending on the gpg wrapper it may look like it. Gpgme is the one I had most issues with raining with fatal errors where gpg on its own only reports a warning.
Non of this is impossible to overcome. Yet, I still was sometimes relied on to debug things.
akoboldfrying 13 hours ago [-]
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...?)
tomjakubowski 13 hours ago [-]
Another trick with github urls: you can append .patch or .diff to any PR or commit URL, and you'll get back a git-formatted patch or diff.
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.)
GPG man page is long. But to be fair, GPG, which I have used for decades, has never failed me.
theteapot 11 hours ago [-]
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.
woodruffw 10 hours ago [-]
The mystery meat in question is GPG, not sops or this.
(I also wouldn’t call GPG a low level dependency.)
theteapot 10 hours ago [-]
lowish. Meaning if you run a Linux desktop env with a mild amount of software installed it's likely pulled in already.
ikiris 7 hours ago [-]
So is Perl, that doesn’t make it a good argument to use it still for the same reasons.
mgarciaisaia 10 hours ago [-]
I didn't know about sops, thanks for sharing!
Encrypting YAML files' values may be handy for another project - will take note of it.
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?
hnlmorg 17 hours ago [-]
Coincidentally I’ve written something similar to this too.
My main takeaway was that GPG isn’t nearly as user friendly as it needs to be.
mmh0000 17 hours ago [-]
Highly true. Yet. If you complain or even offer patches (which will, always, without fail, be rejected).
You'll get told off by the GPG devs with something along the lines of "encryption is supposed to be hard".
upofadown 16 hours ago [-]
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".
9dev 17 hours ago [-]
How hard would it be to devise an easy to use wrapper on top of GPG, kind of porcelain-like?
ognarb 15 hours ago [-]
It already exists and it's called Kleopatra. It's developed by KDE with some support from the GPG developers and is part of the Gpg4Win suite.
It's used by quite a few companies and public administrations.
akerl_ 15 hours ago [-]
The easier and more productive thing is to make an easy-to-use tool that does a specific workflow vs trying to be a swiss army knife.
Signal/Whatsapp/etc that use the Signal Protocal are this for messaging.
It turns out solving one problem at a time and ending up with a bunch of purpose-built tools is way easier to get right than trying to jam an entire toolbox into one thing.
>GnuPG Made Easy (GPGME) is a library designed to make access to GnuPG easier for applications. It provides a High-Level Crypto API for encryption, decryption, signing, signature verification and key management. Currently it uses GnuPG's OpenPGP backend as the default, but the API isn't restricted to this engine. We have, in fact, already developed a backend for CMS (S/MIME).
It isn't exactly a wrapper, but it has an easier to use interface (as well as a more gpg compatible interface).
Valodim 16 hours ago [-]
The correct way to do stuff like this these days with openpgp is to use a SOP (stateless openpgp) implementation. https://www.openpgp.org/about/sop/
bitbasher 18 hours ago [-]
Couldn't you just use pass and have something like this in your bash script/env:
export SOME_SECRET="$(pass show some/secret)"
Piraty 17 hours ago [-]
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
varenc 16 hours ago [-]
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)
asveikau 15 hours ago [-]
I do something like this in my .muttrc. It was showing up in documentation iirc, as the typical way to store credentials for mutt.
ognarb 18 hours ago [-]
I like the idea. GPG encryption are super helful when sharing secrets.
Disclaimer: I work on some UI for GPG as my day job.
dvektor 12 hours ago [-]
I store my secrets in gpg encrypted files and inject them into my environment in my shell rc file.
type of deal. its annoying to put in a password every time i open a new tmux pane but hey, better than plain text.
mgarciaisaia 10 hours ago [-]
That was what I did before knowing about shell-secrets. But I also need different "contexts" on the same domains/tools (different AWS accounts and credentials for different clients), and having none "set" by default prevents me from running _whatever command_ by mistake the majority of the time.
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.
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.
Use keyid instead.
> What happens when your key expires?
GPG will refuse to use it for encryption. Create a new encryption key.
> What happens when the output format changes?
N/A here (?)
> What happens when the key expires and it's attached to a hardware device?
You got me.
If you have an expired GPG private key it will still decrypt things encrypted with the public key.
Non of this is impossible to overcome. Yet, I still was sometimes relied on to debug things.
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
(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".
It's used by quite a few companies and public administrations.
https://github.com/FiloSottile/age is this for encrypting files.
https://en.wikipedia.org/wiki/Signify_(OpenBSD) and https://jedisct1.github.io/minisign/ are this for signing files.
Signal/Whatsapp/etc that use the Signal Protocal are this for messaging.
It turns out solving one problem at a time and ending up with a bunch of purpose-built tools is way easier to get right than trying to jam an entire toolbox into one thing.
>GnuPG Made Easy (GPGME) is a library designed to make access to GnuPG easier for applications. It provides a High-Level Crypto API for encryption, decryption, signing, signature verification and key management. Currently it uses GnuPG's OpenPGP backend as the default, but the API isn't restricted to this engine. We have, in fact, already developed a backend for CMS (S/MIME).
It isn't exactly a wrapper, but it has an easier to use interface (as well as a more gpg compatible interface).
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
Disclaimer: I work on some UI for GPG as my day job.
AWS_SECRET_ACCESS_KEY=$(gpg -d ~/.secrets/aws/key.asc)
type of deal. its annoying to put in a password every time i open a new tmux pane but hey, better than plain text.