d3/123cd91725bb2059bd79117f73c16b201ae426

   1 Return-Path: <dkg@fifthhorseman.net>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5  by arlo.cworth.org (Postfix) with ESMTP id B6F216DE1601\r
   6  for <notmuch@notmuchmail.org>; Wed,  9 Dec 2015 19:40:13 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.033\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.033 tagged_above=-999 required=5\r
  12  tests=[AWL=-0.033] autolearn=disabled\r
  13 Received: from arlo.cworth.org ([127.0.0.1])\r
  14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15  with ESMTP id Gxu-qmnTqJ1x for <notmuch@notmuchmail.org>;\r
  16  Wed,  9 Dec 2015 19:40:12 -0800 (PST)\r
  17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 094F26DE1830\r
  19  for <notmuch@notmuchmail.org>; Wed,  9 Dec 2015 19:40:06 -0800 (PST)\r
  20 Received: from fifthhorseman.net (unknown [38.109.115.130])\r
  21  by che.mayfirst.org (Postfix) with ESMTPSA id 21197F984\r
  22  for <notmuch@notmuchmail.org>; Wed,  9 Dec 2015 22:40:03 -0500 (EST)\r
  23 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
  24  id 9D1AB20548; Wed,  9 Dec 2015 22:40:03 -0500 (EST)\r
  25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
  26 To: Notmuch Mail <notmuch@notmuchmail.org>\r
  27 Subject: allow indexing cleartext of encrypted messages\r
  28 Date: Wed,  9 Dec 2015 22:39:37 -0500\r
  29 Message-Id: <1449718786-28000-1-git-send-email-dkg@fifthhorseman.net>\r
  30 X-Mailer: git-send-email 2.6.2\r
  31 X-BeenThere: notmuch@notmuchmail.org\r
  32 X-Mailman-Version: 2.1.20\r
  33 Precedence: list\r
  34 List-Id: "Use and development of the notmuch mail system."\r
  35  <notmuch.notmuchmail.org>\r
  36 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  37  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  38 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  39 List-Post: <mailto:notmuch@notmuchmail.org>\r
  40 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  41 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  42  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  43 X-List-Received-Date: Thu, 10 Dec 2015 03:40:14 -0000\r
  44 \r
  45 Notmuch currently doesn't index the cleartext of encrypted mail.  This\r
  46 is the right choice by default, because the index is basically\r
  47 cleartext-equivalent, and we wouldn't want every indexed mailstore to\r
  48 leak the contents of its encrypted mails.\r
  49 \r
  50 However, if a notmuch user has their index in a protected location,\r
  51 they may prefer the convenience of being able to search the contents\r
  52 of (at least some of) their encrypted mail.\r
  53 \r
  54 This series of patches enables notmuch to index the cleartext of\r
  55 specific encrypted messages when they're being added via "notmuch new"\r
  56 or "notmuch insert", via a new --try-decrypt flag.\r
  57 \r
  58 If --try-decrypt is used, and decryption is successful for part of a\r
  59 message, the message gets an additional "index-decrypted" tag.  If\r
  60 decryption of part of a message fails, the message gets an additional\r
  61 "index-decryption-failed" tag.\r
  62 \r
  63 This tagging approach should allow people to figure out which messages\r
  64 have been indexed in the clear (or not), and can be used to\r
  65 selectively reindex them in batch with something like:\r
  66 \r
  67 ----------------\r
  68 #!/usr/bin/env python3\r
  69 \r
  70 '''notmuch-reindex.py -- a quick and dirty pythonic mechanism to\r
  71 re-index specific messages in a notmuch database.  This should\r
  72 probably be properly implemented as a subcommand for /usr/bin/notmuch\r
  73 itself'''\r
  74 \r
  75 import notmuch\r
  76 import sys\r
  77 \r
  78 d = notmuch.Database(mode=notmuch.Database.MODE.READ_WRITE)\r
  79 \r
  80 query = sys.argv[1]\r
  81 \r
  82 q = d.create_query(query)\r
  83 \r
  84 for m in q.search_messages():\r
  85     mainfilename = m.get_filename()\r
  86     origtags = m.get_tags()\r
  87     tags = []\r
  88     for t in origtags:\r
  89         if t not in ['index-decrypted', 'index-decryption-failed']:\r
  90             tags += [t]\r
  91     d.begin_atomic()\r
  92     for f in m.get_filenames():\r
  93         d.remove_message(f)\r
  94     (newm,stat) = d.add_message(mainfilename, try_decrypt=True)\r
  95     for tag in tags:\r
  96         newm.add_tag(tag)\r
  97     d.end_atomic()\r
  98 ----------------\r
  99 \r
 100 A couple key points:\r
 101 \r
 102  * There is some code duplication between crypto.c (for the\r
 103    notmuch-client) and lib/database.cc and lib/index.cc (for the\r
 104    library) because both parts of the codebase use gmime to handle the\r
 105    decryption.  I don't want to contaminate the libnotmuch API with\r
 106    gmime implementation details, so i don't quite see how to reuse the\r
 107    code cleanly.  I'd love suggestions on how to reduce the\r
 108    duplications.\r
 109 \r
 110  * the libnotmuch API is extended with\r
 111    notmuch_database_add_message_try_decrypt().  This should probably\r
 112    ultimately be more general, because there are a few additional\r
 113    knobs that i can imagine fiddling at indexing time.  For example:\r
 114 \r
 115     * verifying cryptographic signatures and storing something about\r
 116       those verifications in the notmuch db\r
 117      \r
 118     * extracting OpenPGP session key information for a given message\r
 119       and storing it in a lookaside table in the notmuch db, so that\r
 120       it's possible to securely destroy old encryption-capable keys\r
 121       and still have local access to the cleartext of the remaining\r
 122       messages.\r
 123 \r
 124    Some of these additional features might be orthogonal to one\r
 125    another as well.  I welcome suggestions for how to improve the API\r
 126    so that we don't end up with a combinatorial explosion of\r
 127    n_d_add_message_foo() functions.\r
 128 \r
 129  * To properly complete this patch series, i think i want to make\r
 130    notmuch-reindex.c and add a reindex subcommand, also with a\r
 131    --try-decrypt option.  It's not clear to me if the right approach\r
 132    for that is to have a C implementation of the python script above\r
 133    without modifying libnotmuch, or if i should start by creating a\r
 134    notmuch_message_reindex function in libnotmuch, with a try_decrypt\r
 135    flag.  Again, suggestions welcome.\r
 136 \r
 137  * Is the tagging approach the right thing to do to record success or\r
 138    failure of decryption at index time?  Is there a better approach?\r
 139 \r
 140 \r