Re: Notmuch, Emacs and pinentry -- oh my

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

[-- Attachment #1: Type: text/plain, Size: 2426 bytes --]

On Fri 2019-11-08 16:40:05 +0100, Ralph Seichter wrote:
> I only access the server with a terminal, and that's where Emacs is
> running in. Curses is as graphical as it gets. ;-)

Neither pinentry-tty nor pinentry-curses is designed to work (or capable
of working well) with another process actively sharing the tty to which
it's connected.  That means that having either such interaction in the
same terminal while you're running emacs is probably not going to end
well :/

Have you considered running gpg-agent in a dedicated terminal window,
and handling the gpg-agent prompts from that window?  That would provide
a clean separation between password entry (and other forms of
interaction with the gpg-agent) and interaction with your message store.

My understanding is that this is the recommended way of using gpg-agent
when (a) you have a passphrase-locked secret key, and (b) no graphical
environment is available.

> As for the nuclear option of decoding on indexing: That worries me more
> than using Emacs with some form of pinentry and gpg-agent.

To be clear about your threat model here: an active attacker with access
to your account on the server can relatively easily get a copy of your
secret key in unprotected form.  What they do is intercept your
gpg-agent process, and then next time you enter your password, they use
it to decrypt and exfiltrate your secret key.

So the difference between that situation and a situation where you have
indexed the cleartext is that the same attacker can just raid the
cleartext index directly (e.g. from backups, or from the physical disk
if it's seized), without having to wait to actively intercept your
password.

That's a significant difference, but not a huge one.

If your index was protected (e.g. via an encrypted filesystem), perhaps
you'd feel differently about that tradeoff?

In my queue of things to work on, i've got "notmuch lock" and "notmuch
unlock", which should apply filesystem encryption protection to your
notmuch index.  Is that something you'd be interested in?

note that if you adopt it, then you get a few additional nice features:

 * the ability to search the cleartext of your encrypted messages

 * the ability to destroy old/expired decryption-capable subkey secret
   material without losing access to the cleartext of encrypted messages
   that you want to retain.

happy to talk more about those tradeoffs if you like.

        --dkg

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]