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.
