31–40 of 43 posts
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.) [1]: https://github.com/getsops/sops
Encrypting YAML files' values may be handy for another project - will take note of it.
I store my secrets in gpg encrypted files and inject them into my environment in my shell rc file. 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.
Earlier quoted context omitted.
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.
> 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.
If you have an expired GPG private key it will still decrypt things encrypted with the public key.
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?
Earlier quoted context omitted.
The mystery meat in question is GPG, not sops or this. (I also wouldn’t call GPG a low level dependency.)
lowish. Meaning if you run a Linux desktop env with a mild amount of software installed it's likely pulled in already.
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. 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 manage…
Earlier quoted context omitted.
> 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.
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.
Non of this is impossible to overcome. Yet, I still was sometimes relied on to debug things.
Earlier quoted context omitted.
The mystery meat in question is GPG, not sops or this. (I also wouldn’t call GPG a low level dependency.)
lowish. Meaning if you run a Linux desktop env with a mild amount of software installed it's likely pulled in already.
for a newer password manager... https://github.com/FiloSottile/passage
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.