Hacker News Reader

Comment by technomancy | Hacker News Reader

It's not as simple as you make it out to be. HTTPS git still has no consistent way to cache credentials, so you're stuck either keeping it in plaintext on disk or re-authenticating every time you push.

Even though client TLS certs are technically supported by a handful of services, there's nothing for HTTPS that matches the security and convenience of ssh-agent. It has a long way to go to catch up to where SSH was ten or fifteen years ago.

View on HN

git supports "credential helpers" [0] which allow arbitrary credential storage and retrieval schemes. I've successfully used it with a Yubikey, for example, although I promptly reverted to using SSH and my GPG authentication subkey when it became clear that there is no single scheme that works on all platforms I use.

[0] https://git-scm.com/docs/git-credential

The parent has a great point about credentials and ssh-agent in general. Netrc isn't a great pattern.

But for git you have the right answer.

I completely forgot this aspect because on OS X you can delegate git auth to Keychain with a helper.

https://help.github.com/articles/caching-your-github-passwor...

Apparently since the last time I checked, git actually includes a helper script that allows you to use `gpg-agent` to decrypt your creds in an analogous way to how `ssh-agent` works. It requires a bit of setup since for some reason it's disabled by default, and it's a bit more moving parts (GPG key plus username/password instead of a single keypair) but it's a lot better than it used to be.

I hope this pattern catches on for services other than git.

A better solution is to simply use `gpg-agent` as your `ssh-agent`, as it supports that protocol and it supports RSA authentication keys.

Then your public keys provide not only identity, but services can verify that identity through their web of trust.

Reply on news.ycombinator.com