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
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.)
(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
Disclaimer: I work on some UI for GPG as my day job.
https://bsky.app/profile/filippo.abyssdomain.expert/post/3l5...
Would be interesting to get more context why move from storing passwords locally to an online service.
I still have high-value passwords and CLI credentials in passage + age-plugin-yubikey.
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.
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).
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.
(admittedly AFAIK encryption is handled by key expiry poorly overall in GPG - the lack of perfect forward secrecy means an expired key which leaks can still decrypt all the old messages if they were intercepted).