Re: allow indexing cleartext of encrypted messages

diff --git a/a4/d2740a72cbde26e9d146f86577657a21d7ebde b/a4/d2740a72cbde26e9d146f86577657a21d7ebde
new file mode 100644 (file)
index 0000000..471de46
--- /dev/null
+++ b/a4/d2740a72cbde26e9d146f86577657a21d7ebde
@@ -0,0 +1,114 @@
+Return-Path: <tomi.ollila@iki.fi>\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 4091C6DE0A9A\r
+ for <notmuch@notmuchmail.org>; Fri, 11 Dec 2015 14:05:11 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at cworth.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: 0.697\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[AWL=0.045, \r
+ SPF_NEUTRAL=0.652] 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 vUPSW1kvWmcm for <notmuch@notmuchmail.org>;\r
+ Fri, 11 Dec 2015 14:05:09 -0800 (PST)\r
+Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
+ by arlo.cworth.org (Postfix) with ESMTP id 8A8BC6DE005F\r
+ for <notmuch@notmuchmail.org>; Fri, 11 Dec 2015 14:05:09 -0800 (PST)\r
+Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
+ by guru.guru-group.fi (Postfix) with ESMTP id 1E2D410004A;\r
+ Sat, 12 Dec 2015 00:05:20 +0200 (EET)\r
+From: Tomi Ollila <tomi.ollila@iki.fi>\r
+To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
+ Notmuch Mail <notmuch@notmuchmail.org>\r
+Subject: Re: allow indexing cleartext of encrypted messages\r
+In-Reply-To: <87zixhgfsu.fsf@alice.fifthhorseman.net>\r
+References: <1449718786-28000-1-git-send-email-dkg@fifthhorseman.net>\r
+ <87zixhgfsu.fsf@alice.fifthhorseman.net>\r
+User-Agent: Notmuch/0.21+32~g73439f8 (http://notmuchmail.org) Emacs/24.3.1\r
+ (x86_64-unknown-linux-gnu)\r
+X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
+ $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
+ !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
+Date: Sat, 12 Dec 2015 00:05:20 +0200\r
+Message-ID: <m2y4d063q7.fsf@guru.guru-group.fi>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain\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: Fri, 11 Dec 2015 22:05:11 -0000\r
+\r
+On Fri, Dec 11 2015, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:\r
+\r
+> On Wed 2015-12-09 22:39:37 -0500, Daniel Kahn Gillmor wrote:\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
+> I have a proposal for how to do this better:\r
+>\r
+> I'll introduce a notmuch_index_options_t, with the usual constructors\r
+> and destructors and a couple functions:\r
+>\r
+>   notmuch_index_options_set_try_decrypt()\r
+>   notmuch_index_options_get_try_decrypt()\r
+>   notmuch_index_options_set_gpg_path()\r
+>   notmuch_index_options_get_gpg_path()\r
+>\r
+> Then i'll add:\r
+>\r
+>   notmuch_database_add_message_with_options(db, fname, options, &message)\r
+>\r
+> If we add new indexing features, they can be set directly in the\r
+> index_options object (including features that might be more complex than\r
+> a string or a bool, like a chain of command-line filters).\r
+>\r
+> a few nice features of this approach:\r
+>\r
+>  * The user of the library can craft a set of index options and repeat\r
+>    it easily, and the options can contain cached/lazily-initialized\r
+>    things (like GMimeCryptoContexts) if needed.\r
+>\r
+>  * The user can index different messages with different options if they\r
+>    prefer (no need to set the options on the database object itself)\r
+>\r
+>  * the capability of the indexing features in the library is visible\r
+>    directly in the exposed API.\r
+>\r
+> any thoughts on this?\r
+\r
+sounds good (on paper) (*)\r
+\r
+>\r
+>     --dkg\r
+\r
+Tomi\r
+\r
+(*) deliberately declined to write 'looks good' >;) (but it's good)\r