notmuch show --decrypt=stash
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Mon Dec 11 18:52:20 PST 2017
This series allows "notmuch show" to index the cleartext and stash the
session keys of an encrypted message while displaying it.
Because it uses a keyword argument to --decrypt for "notmuch show", It
needs to be applied *after* the series with the subject:
Encourage explicit arguments for --decrypt in "show" and "reply"
Background
----------
The cleartext indexing and session-keys series make working with
encrypted e-mail significantly easier in notmuch. However, their
underlying assumption is that at the time of message ingestion (and
"notmuch new" in particular), the user is likely to have access to
their long-term secret keys.
In practice, many people using GnuPG today have their secret keys
locked behind a passphrase, or on a smartcard, and also run "notmuch
new" in some sort of scheduled, backgrounded process.
The result is that for users with this workflow, GnuPG prompts for
their passphrase (or to trigger their smartcard) at unpredictable
times, depending on when their mail delivery happens, and on how many
encrypted messages they receive. This is both unfriendly and bad for
security (we should not train users to approve random prompts for
secret key access when nothing they're doing interactively seems to
warrant it).
Outline
-------
For a friendlier experience, some users may prefer incoming encrypted
mail to stay in their inbox *without* being decrypted, until they
choose to look at it. At the moment that they're looking at it, their
MUA is in the foreground and they're interacting with it, so being
prompted for their password or smartcard interactively makes sense at
that time.
This series makes it possible for this interaction to to actually
decrypt the message, index it, and stash any session keys the first
time the user interacts with the message through "notmuch show".
This is not a workflow that every MUA will choose to use (e.g. users
whose decryption-capable secret key is already cheaply available
without hassling the user at "notmuch new" shouldn't use it), but it
is a sensible workflow for some users that notmuch should support.
Furthermore, it is a more efficient use of secret key material -- a
user that wants to stash session keys of a message, but whose
long-term decryption secret key is on a smartcard should only be obliged
to trigger the smartcard once per message, ever.
Implementation details
----------------------
The most controversial part of this series is that it makes "notmuch
show" potentially not a read-only operation on the database. This is
a tradeoff that the users of this workflow will need to consider,
since they are explicitly asking "notmuch show" to potentially modify
their index.
Note that i've made this R/O-to-R/W switch fairly coarse. If the user
requests --decrypt=stash, then "notmuch show" will operate on a
read/write database, regardless of whether the message is actually
encrypted. I used this coarse approach because i couldn't figure out
a safe way to reopen an existing read-only database in read-write
mode. If someone more clever with Xapian than me wants to suggest a
way to do this in a more fine-grained fashion, i'd welcome patches or
pointers.
I welcome review and feedback.
--dkg
More information about the notmuch
mailing list