From 7f12c2a6ebc05485e176301356218d778c913827 Mon Sep 17 00:00:00 2001 From: Daniel Kahn Gillmor Date: Mon, 7 Apr 2014 18:16:50 +2000 Subject: [PATCH] Re: Feature suggestion. Indexing encrypted mail? --- 9e/86ce262bde73ba6bbbc4832395567b80e3a939 | 152 ++++++++++++++++++++++ 1 file changed, 152 insertions(+) create mode 100644 9e/86ce262bde73ba6bbbc4832395567b80e3a939 diff --git a/9e/86ce262bde73ba6bbbc4832395567b80e3a939 b/9e/86ce262bde73ba6bbbc4832395567b80e3a939 new file mode 100644 index 000000000..c1923f1c4 --- /dev/null +++ b/9e/86ce262bde73ba6bbbc4832395567b80e3a939 @@ -0,0 +1,152 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id DB0A9431FB6 + for ; Sun, 6 Apr 2014 15:17:06 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0 +X-Spam-Level: +X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none] + autolearn=disabled +Received: from olra.theworths.org ([127.0.0.1]) + by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id csdNGIu9O2Wv for ; + Sun, 6 Apr 2014 15:17:01 -0700 (PDT) +Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) + by olra.theworths.org (Postfix) with ESMTP id 4BBC7431FBC + for ; Sun, 6 Apr 2014 15:17:01 -0700 (PDT) +Received: from [10.21.2.224] (unknown [107.19.144.191]) + by che.mayfirst.org (Postfix) with ESMTPSA id 8BC18F984; + Sun, 6 Apr 2014 18:16:55 -0400 (EDT) +Message-ID: <5341D252.90405@fifthhorseman.net> +Date: Sun, 06 Apr 2014 18:16:50 -0400 +From: Daniel Kahn Gillmor +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:24.0) Gecko/20100101 Icedove/24.3.0 +MIME-Version: 1.0 +To: Guyzmo , + Jameson Graef Rollins +Subject: Re: Feature suggestion. Indexing encrypted mail? +References: <86k3b3ybo6.fsf@someserver.somewhere> + <878urj1z3j.fsf@maritornes.cs.unb.ca> + <87txa7pp8z.fsf@servo.finestructure.net> + <20140406091516.GG26903@vilya.m0g.net> +In-Reply-To: <20140406091516.GG26903@vilya.m0g.net> +X-Enigmail-Version: 1.6+git0.20140323 +Content-Type: multipart/signed; micalg=pgp-sha512; + protocol="application/pgp-signature"; + boundary="5isNjlwQfkr5DIQNGreml8XkOmff5dB08" +Cc: notmuch@notmuchmail.org, Daniel Kahn Gillmor +X-BeenThere: notmuch@notmuchmail.org +X-Mailman-Version: 2.1.13 +Precedence: list +List-Id: "Use and development of the notmuch mail system." + +List-Unsubscribe: , + +List-Archive: +List-Post: +List-Help: +List-Subscribe: , + +X-List-Received-Date: Sun, 06 Apr 2014 22:17:07 -0000 + +This is an OpenPGP/MIME signed message (RFC 4880 and 3156) +--5isNjlwQfkr5DIQNGreml8XkOmff5dB08 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +On 04/06/2014 05:15 AM, Guyzmo wrote: +> I indeed agree with this view, and I think the best process would b= +e +> to have the MUA decrypt and index an encrypted mail when the user want= +s +> it to be indexed. So the user do not get really highly secret message= +s +> disclosable by the index, and for the others take that kind of risk. + +At the moment, notmuch has a "no-modify" policy to the mail storage, +with the exception of changing a few well-known flags on maildir names. + +I would be pretty sad to see that change, and i don't think that's a +good idea for notmuch in general. let's keep access to the mail store +as read-only as possible. + +additionally, stripping encryption in some cases would mean stripping +cryptographic signatures (e.g. most PGP/MIME encrypted messages are +encrypted+signed, but the signature is a separate PGP part and not a +MIME part) i think it would be bad to lose cryptographic signatures in +this case. + +That said, i agree that there are some scenarios where having +well-indexed mail storage even for the cleartext of encrypted messages +would be useful and could even be done with some level of safety (e.g. +where the index is itself stored on an encrypted filesystem -- notmuch +has no explicit/builtin support for an encrypted index today). + +I think the most sensible way to approach this goal for notmuch would be +a two-part series of generic notmuch enhancements, which could then be +leveraged by those who need them into a cleartext index for those +messages that they are willing to take a risk on. + +here are the notmuch enhancements: + + * notmuch new id:$msgid + +This capability would allow notmuch to reindex a given message, clearing +the entire index of any old references and adding new references to the +current filter. + + * notmuch new --filter=3D$foo + +The --filter option for notmuch new (or something similar) would pass +each message in question through a pipeline-style filter and operate on +it the stdout of the filter, rather than the raw message. + +Given these two enhancements (some of which may be already underway, i +confess i haven't been following closely), it wouldn't be much extra +effort for someone to implement a filter that strips encryption from the +message. (this might still have the problem mentioned above about also +stripping PGP/MIME signatures, but the signatures and the decrypted +message itself would remain intact so they could be shown directly by +notmuch show without trouble). + +once such a filter was in place, my personal preference would be that +the messages would be imported as ciphertext initially, but then when an +end-user-facing MUA gets the user to decrypt a message that has not been +indexed with this filter, it could offer a button that says "index this +message in cleartext (will leak contents to anyone who can read the index= +)" + + --dkg + + +--5isNjlwQfkr5DIQNGreml8XkOmff5dB08 +Content-Type: application/pgp-signature; name="signature.asc" +Content-Description: OpenPGP digital signature +Content-Disposition: attachment; filename="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 +Comment: Using GnuPG with Icedove - http://www.enigmail.net/ + +iQJ8BAEBCgBmBQJTQdJVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w +ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB +NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpc250P/1PrZE8MPGVZxb/lLSr41tSZ +OggjQZhMg3TGPcYkX9UWIOn9QBxfh4Q40Ds1DccrWZeWAnVnwq7biJni3/a1kdBK +xuH5ZC32NqK/VnJftEjibq/oEI9+qozWK2BPea7qLCxD/heoQu1+15EKUpINy4ll +5ohzCxQehYBPG37KlVE02A31MRoWz38XAAbtTT3ajzHC6CeVF75OsPZD2wRG9xM0 +5sfMnntzVvJvQnXW9Iuy/pEZyTpEubwyV2BbDKP8k6Z2sOu+h2AGQii2bimoaB+R +eLUxBGDChoqr2/rEY3yuzCH10DHqdHd8qbRbHXACCLI0uIzqba561cADWC8dEYJa +DQLATAYAY4X/4IAO7tYYHJ+uGgiSdxDi1NW0y3p4CHSO8Xt8NJnc+LmOeMkOKkA0 +la+0SxV7f4okf44f05/cO83wLf/RZU5TUH5fA9GKYCwP6O5Ho2cffSYuF54e0znD +NRpqOiNSZ3qX8Eph0X9RUESqsV7qBPTrkwBUnry44kRf2jO+255k4mCacwOkd6wf +JLIc9TUjQTc78fLt+U9B10bT+xFGAp9TJnXfi3DHTmCnPfDu3O71K/GYwQuKfSzb +RGiEjjTeGZQeQZnbP5TPOZkikdpnaATo24GFCcsr36Tqrniqewh37ejNDTQaBeWG +kBS8SuCPcWU33jp6fANi +=gQuN +-----END PGP SIGNATURE----- + +--5isNjlwQfkr5DIQNGreml8XkOmff5dB08-- -- 2.26.2