allow indexing cleartext of encrypted messages
authorDaniel Kahn Gillmor <dkg@fifthhorseman.net>
Thu, 10 Dec 2015 03:39:37 +0000 (22:39 +1900)
committerW. Trevor King <wking@tremily.us>
Sat, 20 Aug 2016 21:50:08 +0000 (14:50 -0700)
d3/123cd91725bb2059bd79117f73c16b201ae426 [new file with mode: 0644]

diff --git a/d3/123cd91725bb2059bd79117f73c16b201ae426 b/d3/123cd91725bb2059bd79117f73c16b201ae426
new file mode 100644 (file)
index 0000000..f4a1b41
--- /dev/null
@@ -0,0 +1,140 @@
+Return-Path: <dkg@fifthhorseman.net>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+ by arlo.cworth.org (Postfix) with ESMTP id B6F216DE1601\r
+ for <notmuch@notmuchmail.org>; Wed,  9 Dec 2015 19:40:13 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.033\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5\r
+ tests=[AWL=-0.033] autolearn=disabled\r
+Received: from arlo.cworth.org ([127.0.0.1])\r
+ by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
+ with ESMTP id Gxu-qmnTqJ1x for <notmuch@notmuchmail.org>;\r
+ Wed,  9 Dec 2015 19:40:12 -0800 (PST)\r
+Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 094F26DE1830\r
+ for <notmuch@notmuchmail.org>; Wed,  9 Dec 2015 19:40:06 -0800 (PST)\r
+Received: from fifthhorseman.net (unknown [38.109.115.130])\r
+ by che.mayfirst.org (Postfix) with ESMTPSA id 21197F984\r
+ for <notmuch@notmuchmail.org>; Wed,  9 Dec 2015 22:40:03 -0500 (EST)\r
+Received: by fifthhorseman.net (Postfix, from userid 1000)\r
+ id 9D1AB20548; Wed,  9 Dec 2015 22:40:03 -0500 (EST)\r
+From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
+To: Notmuch Mail <notmuch@notmuchmail.org>\r
+Subject: allow indexing cleartext of encrypted messages\r
+Date: Wed,  9 Dec 2015 22:39:37 -0500\r
+Message-Id: <1449718786-28000-1-git-send-email-dkg@fifthhorseman.net>\r
+X-Mailer: git-send-email 2.6.2\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.20\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+ <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
+ <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Thu, 10 Dec 2015 03:40:14 -0000\r
+\r
+Notmuch currently doesn't index the cleartext of encrypted mail.  This\r
+is the right choice by default, because the index is basically\r
+cleartext-equivalent, and we wouldn't want every indexed mailstore to\r
+leak the contents of its encrypted mails.\r
+\r
+However, if a notmuch user has their index in a protected location,\r
+they may prefer the convenience of being able to search the contents\r
+of (at least some of) their encrypted mail.\r
+\r
+This series of patches enables notmuch to index the cleartext of\r
+specific encrypted messages when they're being added via "notmuch new"\r
+or "notmuch insert", via a new --try-decrypt flag.\r
+\r
+If --try-decrypt is used, and decryption is successful for part of a\r
+message, the message gets an additional "index-decrypted" tag.  If\r
+decryption of part of a message fails, the message gets an additional\r
+"index-decryption-failed" tag.\r
+\r
+This tagging approach should allow people to figure out which messages\r
+have been indexed in the clear (or not), and can be used to\r
+selectively reindex them in batch with something like:\r
+\r
+----------------\r
+#!/usr/bin/env python3\r
+\r
+'''notmuch-reindex.py -- a quick and dirty pythonic mechanism to\r
+re-index specific messages in a notmuch database.  This should\r
+probably be properly implemented as a subcommand for /usr/bin/notmuch\r
+itself'''\r
+\r
+import notmuch\r
+import sys\r
+\r
+d = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)\r
+\r
+query = sys.argv[1]\r
+\r
+q = d.create_query(query)\r
+\r
+for m in q.search_messages():\r
+    mainfilename = m.get_filename()\r
+    origtags = m.get_tags()\r
+    tags = []\r
+    for t in origtags:\r
+        if t not in ['index-decrypted', 'index-decryption-failed']:\r
+            tags += [t]\r
+    d.begin_atomic()\r
+    for f in m.get_filenames():\r
+        d.remove_message(f)\r
+    (newm,stat) = d.add_message(mainfilename, try_decrypt=True)\r
+    for tag in tags:\r
+        newm.add_tag(tag)\r
+    d.end_atomic()\r
+----------------\r
+\r
+A couple key points:\r
+\r
+ * There is some code duplication between crypto.c (for the\r
+   notmuch-client) and lib/database.cc and lib/index.cc (for the\r
+   library) because both parts of the codebase use gmime to handle the\r
+   decryption.  I don't want to contaminate the libnotmuch API with\r
+   gmime implementation details, so i don't quite see how to reuse the\r
+   code cleanly.  I'd love suggestions on how to reduce the\r
+   duplications.\r
+\r
+ * the libnotmuch API is extended with\r
+   notmuch_database_add_message_try_decrypt().  This should probably\r
+   ultimately be more general, because there are a few additional\r
+   knobs that i can imagine fiddling at indexing time.  For example:\r
+\r
+    * verifying cryptographic signatures and storing something about\r
+      those verifications in the notmuch db\r
+     \r
+    * extracting OpenPGP session key information for a given message\r
+      and storing it in a lookaside table in the notmuch db, so that\r
+      it's possible to securely destroy old encryption-capable keys\r
+      and still have local access to the cleartext of the remaining\r
+      messages.\r
+\r
+   Some of these additional features might be orthogonal to one\r
+   another as well.  I welcome suggestions for how to improve the API\r
+   so that we don't end up with a combinatorial explosion of\r
+   n_d_add_message_foo() functions.\r
+\r
+ * To properly complete this patch series, i think i want to make\r
+   notmuch-reindex.c and add a reindex subcommand, also with a\r
+   --try-decrypt option.  It's not clear to me if the right approach\r
+   for that is to have a C implementation of the python script above\r
+   without modifying libnotmuch, or if i should start by creating a\r
+   notmuch_message_reindex function in libnotmuch, with a try_decrypt\r
+   flag.  Again, suggestions welcome.\r
+\r
+ * Is the tagging approach the right thing to do to record success or\r
+   failure of decryption at index time?  Is there a better approach?\r
+\r
+\r