Notmuch, Emacs and pinentry -- oh my

Notmuch, Emacs and pinentry -- oh my

[Ralph Seichter]

Not being quite sure if this is the correct mailing list to ask, here we
go anyway:

Using Emacs as a Notmuch client, I occasionally come across email that
is signed and/or encrypted. I am then prompted to a) decide if I trust
the signator or b) to enter my PGP secret key's password.

Alas, in these cases I can tell that Emacs expects input of me, but it
only uses the bottom most two lines to do so, meaning that I cannot
quite read what is expected of me. Assuming that pinentry is involved, I
tried switching between pinentry-curses and pinentry-tty in my shell
profile, but the result is unreadable in both cases. If I use commands
like "pgp -d ..." in the shell, both pinentry variants work fine (in the
case of curse, the prompt is smack in the middle of my terminal window,
as expected).

I have enabled 'allow-emacs-pinentry' in my gpg.conf, but that does not
resolve the issue either, so I would be grateful for advice. Thanks.

-Ralph

Re: Notmuch, Emacs and pinentry -- oh my

[David Bremner]

Ralph Seichter <abbot@monksofcool.net> writes:

> Alas, in these cases I can tell that Emacs expects input of me, but it
> only uses the bottom most two lines to do so, meaning that I cannot
> quite read what is expected of me. Assuming that pinentry is involved, I
> tried switching between pinentry-curses and pinentry-tty in my shell
> profile, but the result is unreadable in both cases. If I use commands
> like "pgp -d ..." in the shell, both pinentry variants work fine (in the
> case of curse, the prompt is smack in the middle of my terminal window,
> as expected).

My only (not always popular advice) w.r.t. pinentry is to use a
graphical pinentry if at all possible.

> I have enabled 'allow-emacs-pinentry' in my gpg.conf, but that does not
> resolve the issue either, so I would be grateful for advice. Thanks.
>

Not all Emacs binaries have support for emacs-pinentry built in. Reading
gpg passphrases (or root passwords) into the same emacs as runs a mail
or irc client makes me nervous personally, but it's up to you. In any
case, if you do want to do that, check the variable
system-configuration-options.

Re: Notmuch, Emacs and pinentry -- oh my

[David Bremner]

David Bremner <david@tethera.net> writes:

> Ralph Seichter <abbot@monksofcool.net> writes:
>
>> Alas, in these cases I can tell that Emacs expects input of me, but it
>> only uses the bottom most two lines to do so, meaning that I cannot
>> quite read what is expected of me. Assuming that pinentry is involved, I
>> tried switching between pinentry-curses and pinentry-tty in my shell
>> profile, but the result is unreadable in both cases. If I use commands
>> like "pgp -d ..." in the shell, both pinentry variants work fine (in the
>> case of curse, the prompt is smack in the middle of my terminal window,
>> as expected).
>
> My only (not always popular advice) w.r.t. pinentry is to use a
> graphical pinentry if at all possible.
>

I guess I should mention the "nuclear" option of decrypting your
messages on indexing. Again, up to you to evaluate the risks, but see
notmuch-config(1) for details.

d

Re: Notmuch, Emacs and pinentry -- oh my

[Ralph Seichter]

* David Bremner:

> My only (not always popular advice) w.r.t. pinentry is to use a
> graphical pinentry if at all possible.

I only access the server with a terminal, and that's where Emacs is
running in. Curses is as graphical as it gets. ;-)

> Not all Emacs binaries have support for emacs-pinentry built
> in. Reading gpg passphrases (or root passwords) into the same
> emacs as runs a mail or irc client makes me nervous personally [...]

See https://www.gnu.org/software/emacs/news/NEWS.26.1, section "The
pinentry.el library has been removed.", remarks about minibuffer
vs. graphical pinentry programs.

I have tried 'epa-pinentry-mode' with both loopback and nil, and I tried
both with and without 'allow-emacs-pinentry' in gpg-agent.conf. It does
not seem to make a difference what I try, though.

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

-Ralph

Re: Notmuch, Emacs and pinentry -- oh my

[Daniel Kahn Gillmor]

[-- 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 --]

Re: Notmuch, Emacs and pinentry -- oh my

[Ralph Seichter]

* Daniel Kahn Gillmor:

> Have you considered running gpg-agent in a dedicated terminal window,
> and handling the gpg-agent prompts from that window?

I tried that by setting GPG_TTY to a fixed terminal, but while this
seemed to work on the first call, the second time I was prompted for a
password it was echoed, in cleartext, to the terminal. Is there a better
method to achieve what you proposed?

> To be clear about your threat model here: [...]

Barring break-ins, nobody but me is logging in on that particular
server, so intercepting gpg-agent would be difficult. Access to the
Notmuch index would not be any easier, unless somebody physically
removed the hard drives.

The lock/unlock operations to seems interesting, and, if it was based on
strong encryption, I would feel more comfortable. Are you thinking of
protecting just the index or the whole Maildir store? The latter would
not work for me, because Dovecot needs to access the data, and if only
the index is protected, I'd still need to decrypt messages within Emacs.

Currently, decryption happens in whatever MUA I am using at that time,
i.e. mostly Notmuch/Emacs and alternatively Thunderbird/Enigmail.

-Ralph

Re: Notmuch, Emacs and pinentry -- oh my

[Daniel Kahn Gillmor]

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

On Mon 2019-11-11 20:10:26 +0100, Ralph Seichter wrote:
> I tried that by setting GPG_TTY to a fixed terminal, but while this
> seemed to work on the first call, the second time I was prompted for a
> password it was echoed, in cleartext, to the terminal. Is there a better
> method to achieve what you proposed?

I don't fully understand the parameters of what you just posted here,
but my understanding is that Werner Koch (GnuPG upstream) expects
pinentry-tty or pinentry-curses to work in this dedicated terminal mode.

If you can post a full and clear description of what you did and how it
did not work as expected to https://dev.gnupg.org/ as a bug report, and
point me to it, i am happy to try to make sure that report gets some
kind of reasonable resolution from upstream (even though i probably
don't have time to solve it myself).

Let me know if you can't get an account working to report a bug on that
system, i can probably grease the skids there too.

>> To be clear about your threat model here: [...]
>
> Barring break-ins, nobody but me is logging in on that particular
> server, so intercepting gpg-agent would be difficult. Access to the
> Notmuch index would not be any easier, unless somebody physically
> removed the hard drives.
>
> The lock/unlock operations to seems interesting, and, if it was based on
> strong encryption, I would feel more comfortable. Are you thinking of
> protecting just the index or the whole Maildir store? The latter would
> not work for me, because Dovecot needs to access the data, and if only
> the index is protected, I'd still need to decrypt messages within Emacs.

This hypothetical subcommand would just protect the index.

If the index is unlocked, and you're using:

   notmuch config set index.decrypt true

Then you will be able to read your mail without access to your long-term
secret key material because notmuch will stash a copy of the session key
for each message in the index, and decryption can happen with that
session key on its own.  please read the index.decrypt section of
notmuch-config(1) for more details.

Regards,

        --dkg

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

Re: Notmuch, Emacs and pinentry -- oh my

[Ralph Seichter]

* Daniel Kahn Gillmor:

> This hypothetical subcommand would just protect the index. [...] you
> will be able to read your mail without access to your long-term secret
> key material [...]

That sounds useful, as does the idea of (un)locking the index. As you
may have seen on the GnuPG mailing list, I have not yet cracked the nut
of pass phrase input in Emacs.

-Ralph