b1/10fed78f940a6b2be0a51c416ce39dcc44adde

   1 Return-Path: <james@jameswestby.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 olra.theworths.org (Postfix) with ESMTP id D3805431FBC\r
   6         for <notmuch@notmuchmail.org>; Fri,  8 Jan 2010 02:37:52 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id OVTNwNJgBtQS for <notmuch@notmuchmail.org>;\r
  11         Fri,  8 Jan 2010 02:37:52 -0800 (PST)\r
  12 Received: from jameswestby.net (jameswestby.net [89.145.97.141])\r
  13         by olra.theworths.org (Postfix) with ESMTP id 29984431FAE\r
  14         for <notmuch@notmuchmail.org>; Fri,  8 Jan 2010 02:37:52 -0800 (PST)\r
  15 Received: from cpc4-aztw22-2-0-cust59.aztw.cable.virginmedia.com\r
  16         ([94.169.116.60] helo=flash)\r
  17         by jameswestby.net with esmtpa (Exim 4.69)\r
  18         (envelope-from <james@jameswestby.net>)\r
  19         id 1NTCE2-0007aV-Ik; Fri, 08 Jan 2010 10:37:50 +0000\r
  20 Received: by flash (Postfix, from userid 1000)\r
  21         id B3E6A605C07; Fri,  8 Jan 2010 10:37:44 +0000 (GMT)\r
  22 From: James Westby <jw+debian@jameswestby.net>\r
  23 To: martin f krafft <madduck@madduck.net>, notmuch@notmuchmail.org\r
  24 In-Reply-To: <20100108025610.GA28357@lapse.rw.madduck.net>\r
  25 References: <20091123130009.GA31695@finestructure.net>\r
  26         <20091126060132.GA5875@finestructure.net>\r
  27         <20100108025610.GA28357@lapse.rw.madduck.net>\r
  28 Date: Fri, 08 Jan 2010 10:37:44 +0000\r
  29 Message-ID: <87d41kg9vr.fsf@jameswestby.net>\r
  30 MIME-Version: 1.0\r
  31 Content-Type: text/plain; charset=us-ascii\r
  32 Subject: Re: [notmuch] indexing encrypted messages (was:  OpenPGP support)\r
  33 X-BeenThere: notmuch@notmuchmail.org\r
  34 X-Mailman-Version: 2.1.13\r
  35 Precedence: list\r
  36 List-Id: "Use and development of the notmuch mail system."\r
  37         <notmuch.notmuchmail.org>\r
  38 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  39         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  40 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  41 List-Post: <mailto:notmuch@notmuchmail.org>\r
  42 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  43 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  44         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  45 X-List-Received-Date: Fri, 08 Jan 2010 10:37:53 -0000\r
  46 \r
  47 On Fri, 8 Jan 2010 15:56:10 +1300, martin f krafft <madduck@madduck.net> wrote:\r
  48 > also sprach Jameson Graef Rollins <jrollins@finestructure.net> [2009.11.26.1901 +1300]:\r
  49 > > I would really like to start using notmuch with emacs beyond just\r
  50 > > testing, but I really need to be able to handle/read/send mail with\r
  51 > > PGP/MIME encoded attachments.  Do folks have any suggestions on how to\r
  52 > > handle this?  Is there a separate emacs mode that people use for\r
  53 > > signing/verifying/{de,en}crypting mail buffers, or is this something\r
  54 > > that is going to have to be integrated into the notmuch mode?  I guess\r
  55 > > the notmuch-show mode at least will need to do some verifying and\r
  56 > > decrypting.\r
  57 > \r
  58 > How about indexing GPG-encrypted messages?\r
  59 \r
  60 I think the difficulty will be interactivity. If notmuch-new can\r
  61 potentially block watiting for a passphrase then it's not going to be\r
  62 much use for non-interactive use, and whether someone can respond to a\r
  63 GPG prompt is harder to determine that isatty().\r
  64 \r
  65 Configuration may be a possible way around that, but looking at other\r
  66 things such as opportunistic indexing could be good. For instance,\r
  67 it could be the job of the UIs to decrypt content, and there could be a\r
  68 nomuch function which takes a message id and decrypted content and\r
  69 indexes it in to the DB. That means it's under the UI's control, where\r
  70 the decryption UI should be, gets you indexing of encrypted content.\r
  71 \r
  72 That would leave an open question over whether future notmuch show\r
  73 invocations would return the plaintext or ciphertext. If it is the\r
  74 latter then it requires decrypting every time you want to view it, but\r
  75 it does mean that there is less information leakage (you could find out\r
  76 whether an encrypted message contained a particular term, but not read\r
  77 the whole message directly).\r
  78 \r
  79 Thanks,\r
  80 \r
  81 James\r