Re: Feature suggestion. Indexing encrypted mail?
authorJameson Graef Rollins <jrollins@finestructure.net>
Sat, 5 Apr 2014 19:09:32 +0000 (12:09 +1700)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 18:01:16 +0000 (10:01 -0800)
22/523690ad4ec80094aada4aea2874bdaf03c046 [new file with mode: 0644]

diff --git a/22/523690ad4ec80094aada4aea2874bdaf03c046 b/22/523690ad4ec80094aada4aea2874bdaf03c046
new file mode 100644 (file)
index 0000000..c5cccbe
--- /dev/null
@@ -0,0 +1,131 @@
+Return-Path: <jrollins@finestructure.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 olra.theworths.org (Postfix) with ESMTP id F3F21431FB6\r
+       for <notmuch@notmuchmail.org>; Sat,  5 Apr 2014 12:09:45 -0700 (PDT)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.525\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.525 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_MED=-2.3, URIBL_BLACK=1.775] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id syYfQM4BJGfF for <notmuch@notmuchmail.org>;\r
+       Sat,  5 Apr 2014 12:09:39 -0700 (PDT)\r
+Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu\r
+       [131.215.239.19])\r
+       by olra.theworths.org (Postfix) with ESMTP id 62DC6431FAF\r
+       for <notmuch@notmuchmail.org>; Sat,  5 Apr 2014 12:09:39 -0700 (PDT)\r
+Received: from fire-doxen.imss.caltech.edu (localhost [127.0.0.1])\r
+       by fire-doxen-postvirus (Postfix) with ESMTP id B813532820C;\r
+       Sat,  5 Apr 2014 12:09:36 -0700 (PDT)\r
+X-Spam-Scanned: at Caltech-IMSS on fire-doxen by amavisd-new\r
+Received: from finestructure.net (cpe-107-185-189-81.socal.res.rr.com\r
+       [107.185.189.81]) (Authenticated sender: jrollins)\r
+       by fire-doxen-submit (Postfix) with ESMTP id 464F63280C3;\r
+       Sat,  5 Apr 2014 12:09:35 -0700 (PDT)\r
+Received: by finestructure.net (Postfix, from userid 1000)\r
+       id C095260124; Sat,  5 Apr 2014 12:09:34 -0700 (PDT)\r
+From: Jameson Graef Rollins <jrollins@finestructure.net>\r
+To: David Bremner <david@tethera.net>, john.wyzer@gmx.de,\r
+       notmuch@notmuchmail.org\r
+Subject: Re: Feature suggestion. Indexing encrypted mail?\r
+In-Reply-To: <878urj1z3j.fsf@maritornes.cs.unb.ca>\r
+References: <86k3b3ybo6.fsf@someserver.somewhere>\r
+       <878urj1z3j.fsf@maritornes.cs.unb.ca>\r
+User-Agent: Notmuch/0.17+174~gaa1f476 (http://notmuchmail.org) Emacs/24.3.1\r
+       (x86_64-pc-linux-gnu)\r
+Date: Sat, 05 Apr 2014 12:09:32 -0700\r
+Message-ID: <87txa7pp8z.fsf@servo.finestructure.net>\r
+MIME-Version: 1.0\r
+Content-Type: multipart/signed; boundary="=-=-=";\r
+       micalg=pgp-sha256; protocol="application/pgp-signature"\r
+Cc: Daniel Kahn Gillmor <dkg@debian.org>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://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: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Sat, 05 Apr 2014 19:09:46 -0000\r
+\r
+--=-=-=\r
+Content-Type: text/plain\r
+Content-Transfer-Encoding: quoted-printable\r
+\r
+On Sat, Apr 05 2014, David Bremner <david@tethera.net> wrote:\r
+> john.wyzer@gmx.de writes:\r
+>\r
+>> Would it be possible to add the configurable option to also decrypt\r
+>> encrypted messages on the fly while indexing to make them searchable,\r
+>> too?\r
+>>\r
+>> That would be really great for people that consider gnupg  mainly an\r
+>> encryption for transport or have their complete hard drive encrypted...\r
+>\r
+> As far I understand an attacker could reconstruct the message from the\r
+> index, so one question is whether the extra complexity in notmuch is\r
+> worth the minimal extra security over decrypting on delivery and storing\r
+> plaintext on the (presumably encrypted) disk. Of course decrypting on\r
+> delivery may be inconvenient (or impossible). I have CCed the two people\r
+> who have implemented most of the crypto related stuff in notmuch so they\r
+> can comment.\r
+\r
+Indexing encrypted email is a bit of a foot-gun, since, as David\r
+mentions, it is apparently possible to reconstruct encrypted messages\r
+From=20the index.  It therefore needs to be approached with care.\r
+\r
+I think decrypting on "delivery" (or mail fetch or whatever) sounds\r
+difficult and unwieldy.  In either event, it seems out of the scope of\r
+notmuch.  If a user figured out how to have that done, no changes to\r
+notmuch would be needed afaict.\r
+=20\r
+I don't think it would be difficult modify notmuch new to decrypt at\r
+indexing time.  Given that gnupg agent would be used for accessing the\r
+users private key for decryption, the interface would be fairly\r
+straightforward.\r
+\r
+A couple of decryption options could be added to notmuch new:\r
+\r
+* don't decrypt: don't attempt to decrypt and index any encrypted\r
+  message (default)\r
+\r
+* decrypt always: fail if any encrypted message could not be decrypted\r
+\r
+* decrypt opportunistically: attempt to decrypt, but continue indexing\r
+  if an encrypted message could not be decrypted\r
+\r
+If something like this is enabled, we should make sure we make the\r
+dangers clear to the users.\r
+\r
+jamie.\r
+\r
+--=-=-=\r
+Content-Type: application/pgp-signature\r
+\r
+-----BEGIN PGP SIGNATURE-----\r
+Version: GnuPG v1\r
+\r
+iQIcBAEBCAAGBQJTQFTsAAoJEO00zqvie6q83QkQAJ17ZJ60k5CrPZotnd/hx5L/\r
+/Qe4ovlLCKECK+P10bK7YmlH350ujnX5YsgO00QEbvaS09nTDofRpvE9zZiWvlPr\r
+MTdqnJ5p9iz6+LsELRerDEMMxEgLtUgSD/tNVCZWJJ5sUC3TwznJMCLLdkYmwRRe\r
+EflzG0ASIb4ooL6oeyDcsbtir2A11232bPd+AL+WZFzfXXvBEBvbqGX8fwujZ6IY\r
+95xd3bT9IpVgk8TbKdY5Smor6K5nZfmm5TM2/O8fjt4bwKUJAhj2OCkUbEgpw+RP\r
+VeYV9+2B5iEAYQFKNEDdLr1vumln2p30WcnvJpEFwzE6nwtRzbW0VZ2BfJsl40qn\r
+FpXYOyudOhh3cwDgXDcv1ubvILuys+nu5vWsx2xdn8Lg7EDYIsA33NHr1rH9Laj0\r
+kliU4ySLdwOrHUKvr63aVXMt+FwhfBWdR6CtQa+m5nZIR6tUC8MxyU4ROxtK37EA\r
+7s15rIqce/dvyyskKv57a0V79bTARICPR8xERIwANcSlVv8LH9iAC1R23UoSaT8J\r
+7XEKicuMcsQawkDcIJYEYu+FUOtfb8DqRrMZ5WaWYYu9FRuYEG5Uuq9otu49IIEG\r
+ePkDUreFfEBs0Pu/1PU8r+sjmK41pcuHhd7SuqzrCzpwf9+v6q7kHMsZywhrRfbk\r
+MtNEBcRJujCfQZ/QZIzv\r
+=4Tws\r
+-----END PGP SIGNATURE-----\r
+--=-=-=--\r