[rdl]

In reality, the biggest risk for routine comsec with pgp is that no one uses it because it's difficult, but the very specific app of code signing is something where keys need a lot of protection IMO. (I am mostly fine with START TLS for email security 99.99% of the time)

The thing which terrifies me is that the npm keybase app asks for my GPG key directly in the same window, and it's impossible for me to (easily) tell when the password prompt is from my GPG binary (which I pretty much trust) vs. the npm binary.

I'm using keybase now (rdl), mostly because I trust Chris Coyne personally, and because my key is old. I'm creating a new 4096 RSA key soon, and will be a lot more paranoid about protecting it -- it will only ever exist on read/use only smartcards after initial generation on a secure machine. (sadly, openpgp card doesn't support export and replication, so to be durable, I have to generate it externally and load onto a bunch of cards and then delete the external key; I'm not willing to trust my keys to a single smartcard I carry with me.)

Using keybase with gpg agent is maybe a bit safer. I don't really mind being forced to do bad stuff by keybase, due to the risks to them if they're caught, as long as it doesn't expose my keying material. gpg agent plus a hardware smartcard should mostly protect me. The pure-software alternative would be a bunch of text-file messages which I can manually cut and paste and move around between clearly-distinct processes running in separate shells/windows (or machines!).

I've been thinking about something a lot better than openpgp card, though, as a secure end-user key management device, with more than just key protections. Unfortunately that means making custom hardware, and that makes little sense in the volumes PGP achieves; maybe if there are other client-side security credentials like ssh or bitcoin, I'd do it.

[maxtaco]

There's one instance in which we prompt for your PGP password directly, since gpg doesn't give us command line access to the needed feature: that's adding the username <[e-mail]> to your public key if it's not already there. Aside from that, we never need your PGP password and just rely on gpg to prompt for it when needed. If you're seeing other prompts, it could be bug, please let us know!

[rdl]

The point is that in a terminal window I have no idea what comes from the keybase binary vs. the gnupg binary it calls out to. You could throw up a convincing looking prompt, steal my passphrase (optionally crashing or passing it on to the real binary to delay suspicion), and then send the key and the passphrase back to your servers.

Realistically, I'm not going to validate the keybase binary, npm, etc. every time I update the app. (and even if I am, many users won't). And a "user of interest" could be given a "special" binary pretty easily.

[maxtaco]

Agreed. We wish there was a practical solution to this problem, but at some point, it's turtles all the way down.

[rdl]

If your binary output a text file or whatever with commands for GPG, which I could then execute and put back into keybase, that would solve the problem.

I agree, usability nightmare, but it would be a nice paranoid option.

[maxtaco]

Hmm, interesting idea. In general, there is only one sensitive operation per keybase invocation (though many signature verifications that use only public keys), so this is doable but cumbersome.

[rlpb]

If you care about this, then use an agent (eg. gpg-agent). With this general mechanism, you can arrange your own system, including something out-of-band if you wish.

[mitochondrion]

I'm three days late, but I'm interested in Keybase and wondering if I could bum an invite from you.

[zobzu]

Anyone using gpgme will trigger the pinentry program, which you can make recognisable if you need a trusted UI.

Or, if paranoid enough, you can store the key on a stick (like a cryptostick) - in this case, it doesn't matter what you type in since the key never escapes.

Note that this is all while assuming that you do not trust what runs on your computer.