LWN: Comments on "notmuch release 0.26 now available"

notmuch release 0.26 now available

dd9jn — Wed, 17 Jan 2018 21:27:40 +0000

A couple of years ago we did a prototype for KDE using gpg to protect a random access index. This worked using an EncFS container managed by the new g13 tool which encrypted the symmetric key using a gpg public key pair. KDE went into another direction and the code is probably pretty rotten now. Later I changed g13 to work with dmcrypt and that is how I now manage my encrypted partitions. If you are interested please ask over at gnupg-devel.

notmuch release 0.26 now available

dkg — Wed, 17 Jan 2018 15:02:29 +0000

you're welcome! I hope you find it useful :)

GnuPG strives mightily to be cross-platform, and even offers an filesystem container encryption tool called g13, but it is not ready for public consumption.

But even if g13 were ready for prime time, for something like notmuch, where storage access latency is likely to be a critical concern, choosing a platform-specific tool is likely to be faster and more efficient.

Finally, there's a question of storage allocation -- if the user has to have a separate filesystem entirely for their mail index, that means that they need to decide ahead of time how big the index can be so that they can allocate the backing storage -- and unfortunately, this isn't really an answerable question. So I'm leaning in the direction of making it fast on at least one platform that i can test with (ext4/e4crypt on GNU/Linux), exposing a minimalist and sensible UI at the notmuch layer, and if other developers that prefer other platforms (APFS on OS X? btrfs on GNU/Linux? ext4 on Android? dm-crypt on GNU/Linux?) want to build out the same functionality, we can sort out how to make it work there.

notmuch release 0.26 now available

mxmehl — Wed, 17 Jan 2018 12:59:27 +0000

Thanks for the long-term work you've put into the new decrypt/reindex commands, I really look forward to test the 0.26 with my many encrypted mails.

> That said, for people who aren't sure how to best secure their index, i'd be interested in working on "notmuch lock" and "notmuch unlock" subcommands, which could protect the entire index (and maybe even the entire mail store?) using local filesystem-based encryption.

That would be great to mitigate the possible risks of storing the decrypted content in the index! I'm no programmer but couldn't GnuPG be the more platform-independent solution which is always well-integrated in most systems? Most privacy-aware people interested in such a feature will already have a gpg key.

notmuch release 0.26 now available

dkg — Wed, 10 Jan 2018 21:00:03 +0000

As donio points out below, notmuch leaves it up to the user to secure their index, and defaults to not indexing cleartext at all.

That said, for people who aren't sure how to best secure their index, i'd be interested in working on "notmuch lock" and "notmuch unlock" subcommands, which could protect the entire index (and maybe even the entire mail store?) using local filesystem-based encryption.

In my speculative designs, this is likely to initially be a simple wrapper around e4crypt for those people using ext4 as their local filesystem (people with other filesystems can suggest other approaches, i guess). I welcome further discussion about this approach, either here or over on the notmuch mailing list.

notmuch release 0.26 now available

dkg — Wed, 10 Jan 2018 20:54:50 +0000

Hi there! I'm one of the contributors to this feature in notmuch.

Many people use notmuch while syncing their local mail storage with IMAP. if you permanently decrypt your local mail storage, then you're likely to push the cleartext back into IMAP on the next sync.

Additionally, if you decrypt a message permanently, then your local copy of the message will lose whatever other information may have been available in the encryption layer itself -- for example, you'll lose knowledge of the cipher used for encryption, metadata about other targeted keys, etc. If the message was both signed and encrypted, and that was done at the same "layer" (i.e., it is not MIME-clearsigned message that has itself been encrypted), most existing OpenPGP e-mail toolkits will drop the signature entirely.

Speed-wise, if you use the session-key caching features in notmuch 0.26, rendering encrypted mail that has already been indexed is significantly faster than it used to be. I've seen reports of a 8× speedup when rendering large encrypted threads, since no asymmetric crypto is needed. So it doesn't cost much to keep the encrypted copy around and render it in the clear when needed.

Finally, it's just generally good archival practice to leave your incoming messages untouched -- you never know what information or metadata you might need from the message.

notmuch release 0.26 now available

donio — Wed, 10 Jan 2018 19:01:47 +0000

It's optional and off by default. The documentation and help message for the config option warns the user to consider security implications:

index.try_decrypt
[STORED IN DATABASE] When indexing an encrypted e-mail message, if this variable is set to true, notmuch will try to decrypt the message and index the cleartext. Be aware that the index is likely sufficient to reconstruct the cleartext of the message itself, so please ensure that the notmuch message index is adequately protected. DO NOT USE index.try_decrypt=true without considering the security of your index.

Default: false.

notmuch release 0.26 now available

hkario — Wed, 10 Jan 2018 18:05:51 +0000

because it's an indexer, not a MUA, it can't/shouldn't rewrite the files it is processing

and in general I'd say it's easier to keep the files in encrypted form than deal with all the immutability issues that decryption and saving the decrypted version would bring

notmuch release 0.26 now available

welinder — Wed, 10 Jan 2018 16:36:05 +0000

That doesn't seem to be the case as I read it.

It seems they are merging the inconvenience of encrypted mail with the unprotected
nature of plain text mail.

If there is some kind of trade-off there, I don' t see it. Why keep things encrypted
if the contents is leaked via the index?

notmuch release 0.26 now available

bandrami — Wed, 10 Jan 2018 15:56:04 +0000

> It's now possible to include the cleartext of encrypted e-mails in the notmuch index

Err... I hope the index itself is encrypted, in that case?