Hacker News Reader

Comment by viraptor | Hacker News Reader

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 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.

View on HN

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...?)

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.

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

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.

The tool is just pulling one encryption key from your local GPG keyring. What's to maintain?

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.

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.

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.

Gonna have to give that a try because it sounds like a very bad interpretation of the expiry mechanism in keys - encryption functionally never expires if you have the key, because you have the key. It's solely an error on the part of the sender to use an expired key, because it might be no longer available.

(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).

Reply on news.ycombinator.com