a4/d2740a72cbde26e9d146f86577657a21d7ebde

   1 Return-Path: <tomi.ollila@iki.fi>\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 4091C6DE0A9A\r
   6  for <notmuch@notmuchmail.org>; Fri, 11 Dec 2015 14:05:11 -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.697\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0.697 tagged_above=-999 required=5 tests=[AWL=0.045, \r
  12  SPF_NEUTRAL=0.652] 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 vUPSW1kvWmcm for <notmuch@notmuchmail.org>;\r
  16  Fri, 11 Dec 2015 14:05:09 -0800 (PST)\r
  17 Received: from guru.guru-group.fi (guru.guru-group.fi [46.183.73.34])\r
  18  by arlo.cworth.org (Postfix) with ESMTP id 8A8BC6DE005F\r
  19  for <notmuch@notmuchmail.org>; Fri, 11 Dec 2015 14:05:09 -0800 (PST)\r
  20 Received: from guru.guru-group.fi (localhost [IPv6:::1])\r
  21  by guru.guru-group.fi (Postfix) with ESMTP id 1E2D410004A;\r
  22  Sat, 12 Dec 2015 00:05:20 +0200 (EET)\r
  23 From: Tomi Ollila <tomi.ollila@iki.fi>\r
  24 To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,\r
  25  Notmuch Mail <notmuch@notmuchmail.org>\r
  26 Subject: Re: allow indexing cleartext of encrypted messages\r
  27 In-Reply-To: <87zixhgfsu.fsf@alice.fifthhorseman.net>\r
  28 References: <1449718786-28000-1-git-send-email-dkg@fifthhorseman.net>\r
  29  <87zixhgfsu.fsf@alice.fifthhorseman.net>\r
  30 User-Agent: Notmuch/0.21+32~g73439f8 (http://notmuchmail.org) Emacs/24.3.1\r
  31  (x86_64-unknown-linux-gnu)\r
  32 X-Face: HhBM'cA~<r"^Xv\KRN0P{vn'Y"Kd;zg_y3S[4)KSN~s?O\"QPoL\r
  33  $[Xv_BD:i/F$WiEWax}R(MPS`^UaptOGD`*/=@\1lKoVa9tnrg0TW?"r7aRtgk[F\r
  34  !)g;OY^,BjTbr)Np:%c_o'jj,Z\r
  35 Date: Sat, 12 Dec 2015 00:05:20 +0200\r
  36 Message-ID: <m2y4d063q7.fsf@guru.guru-group.fi>\r
  37 MIME-Version: 1.0\r
  38 Content-Type: text/plain\r
  39 X-BeenThere: notmuch@notmuchmail.org\r
  40 X-Mailman-Version: 2.1.20\r
  41 Precedence: list\r
  42 List-Id: "Use and development of the notmuch mail system."\r
  43  <notmuch.notmuchmail.org>\r
  44 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
  45  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  46 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
  47 List-Post: <mailto:notmuch@notmuchmail.org>\r
  48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  49 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
  50  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  51 X-List-Received-Date: Fri, 11 Dec 2015 22:05:11 -0000\r
  52 \r
  53 On Fri, Dec 11 2015, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:\r
  54 \r
  55 > On Wed 2015-12-09 22:39:37 -0500, Daniel Kahn Gillmor wrote:\r
  56 >>  * the libnotmuch API is extended with\r
  57 >>    notmuch_database_add_message_try_decrypt().  This should probably\r
  58 >>    ultimately be more general, because there are a few additional\r
  59 >>    knobs that i can imagine fiddling at indexing time.  For example:\r
  60 >>\r
  61 >>     * verifying cryptographic signatures and storing something about\r
  62 >>       those verifications in the notmuch db\r
  63 >>      \r
  64 >>     * extracting OpenPGP session key information for a given message\r
  65 >>       and storing it in a lookaside table in the notmuch db, so that\r
  66 >>       it's possible to securely destroy old encryption-capable keys\r
  67 >>       and still have local access to the cleartext of the remaining\r
  68 >>       messages.\r
  69 >>\r
  70 >>    Some of these additional features might be orthogonal to one\r
  71 >>    another as well.  I welcome suggestions for how to improve the API\r
  72 >>    so that we don't end up with a combinatorial explosion of\r
  73 >>    n_d_add_message_foo() functions.\r
  74 >\r
  75 > I have a proposal for how to do this better:\r
  76 >\r
  77 > I'll introduce a notmuch_index_options_t, with the usual constructors\r
  78 > and destructors and a couple functions:\r
  79 >\r
  80 >   notmuch_index_options_set_try_decrypt()\r
  81 >   notmuch_index_options_get_try_decrypt()\r
  82 >   notmuch_index_options_set_gpg_path()\r
  83 >   notmuch_index_options_get_gpg_path()\r
  84 >\r
  85 > Then i'll add:\r
  86 >\r
  87 >   notmuch_database_add_message_with_options(db, fname, options, &message)\r
  88 >\r
  89 > If we add new indexing features, they can be set directly in the\r
  90 > index_options object (including features that might be more complex than\r
  91 > a string or a bool, like a chain of command-line filters).\r
  92 >\r
  93 > a few nice features of this approach:\r
  94 >\r
  95 >  * The user of the library can craft a set of index options and repeat\r
  96 >    it easily, and the options can contain cached/lazily-initialized\r
  97 >    things (like GMimeCryptoContexts) if needed.\r
  98 >\r
  99 >  * The user can index different messages with different options if they\r
 100 >    prefer (no need to set the options on the database object itself)\r
 101 >\r
 102 >  * the capability of the indexing features in the library is visible\r
 103 >    directly in the exposed API.\r
 104 >\r
 105 > any thoughts on this?\r
 106 \r
 107 sounds good (on paper) (*)\r
 108 \r
 109 >\r
 110 >     --dkg\r
 111 \r
 112 Tomi\r
 113 \r
 114 (*) deliberately declined to write 'looks good' >;) (but it's good)\r