From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id C938F6DE1422 for ; Sun, 26 May 2019 15:16:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.176 X-Spam-Level: X-Spam-Status: No, score=-0.176 tagged_above=-999 required=5 tests=[AWL=0.025, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7zw_UYPFD8X for ; Sun, 26 May 2019 15:16:23 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTPS id 275496DE138E for ; Sun, 26 May 2019 15:16:20 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1558908978; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : from; bh=Hnn/l3SSj0e2CLBJjFchpOlywKK2T+/JuBEQYCSGHVI=; b=/820FbqK/8RnzZj/ho3Uze4v/cbNAQkO08FIqUfN3fHK2E7kqJgIi2CA McJSMgnO4xcOXiCbC/F3R+dzawr4CA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1558908978; h=from : to : subject : date : message-id : mime-version : content-transfer-encoding : from; bh=Hnn/l3SSj0e2CLBJjFchpOlywKK2T+/JuBEQYCSGHVI=; b=bk7epCnpC3q/N04AqtFMrzCCRpcZHwr4xgxlE2IaiKkZIrecKOJuTjqY J1jltII5+VHEXkOVKIVe1QTjqxgLcfKUKd9KMnZqSGe9pakN36hU1TRFS0 SOboIfPRJmipmq1d1uqY7yJ93wlHt890o6rXDju78UKsVrPqDLTX+/gtYD PMz7GWGNELtmxY4aVpthaC4ne/73ebLVbrWHxaEpPYsKVVYzg9nRE6MqIU fsg1HyNkRzNANFyV+uw/e8KqfILh5fJYQZ/RSfvEseLXjqAB88+66Qvy/F Jr4bW0q6xNLMaxl3zOe4jfq8R0CdVlFB07Bp3zGhcEHaTb8ltNdHhQ== Received: from fifthhorseman.net (cpe-74-71-53-242.nyc.res.rr.com [74.71.53.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id EAACBF9A3 for ; Sun, 26 May 2019 18:16:17 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 3D3BA2024B; Sun, 26 May 2019 18:16:14 -0400 (EDT) From: Daniel Kahn Gillmor To: Notmuch Mail Subject: Protected Headers (2nd major revision, more testing!) Date: Sun, 26 May 2019 18:15:53 -0400 Message-Id: <20190526221610.2833-1-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.20.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.29 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, 26 May 2019 22:16:23 -0000 Hi all-- Way back in id:20180511055544.13676-1-dkg@fifthhorseman.net, i proposed support for protected headers (in particular, for being able to read and search for subject lines of encrypted messages which protect the Subject). Although that series was reviewed by Bremner, i never managed to get it in shape for merging. This is a revision of that series, applied against the current master, having taken into account those reviews and the current state of the notmuch codebase. I'm hoping that we can get it into 0.29 before the feature freeze. The major change since the earlier version is that i've dropped the proposed --protected-subject flag for "notmuch reply". An MUA that wants to reply to an encrypted message needs to keep a lot of state active during message composition, including the fact that it was a reply to an encrypted message, and so forth. It needs to know that if the user switches encryption off or on during message composition (for whatever reason, like adding a Cc to someone for whom we don't have keys, or discovering that some of the recipients keys are no longer valid), it needs to think about whether the subject line is stripped or not actively, and passing a simple --protected-subject flag to "notmuch reply" during the initial setup of message composition is insufficient for that purpose. So this series doesn't pretend to handle that case directly -- clients will need to consider it themselves. See the message in commit "cli/reply: ensure encrypted Subject: line does not leak in the clear" for more thoughts about what a reasonable replying MUA might do. This series also (like its earlier incarnation) doesn't get all the way to the point of generating encrypted or signed messages that protect their Subject lines. That might require some e-lisp hackery that i haven't done; or it might be best solved by a "notmuch deliver" outbound message handler (which is also work i haven't done). Or maybe there's some other better solution that i haven't thought of yet. I welcome discussion and suggestions along those lines. The other thing this series does not do is to expose information about the protected headers through the library or the python bindings. I think the pieces are in place to make that happen, but I have not considered the API deeply enough to take a concrete attempt. Again, suggestions (and patches) welcome! However, despite the above-mentioned limitations, this series delivers a concrete improvement: users of notmuch can now read, index, and search for the subject lines of encrypted messages sent from MUAs like Enigmail and K-9 mail. Also: please don't be scared of the length of this series. Although there are 17 patches, the distinct majority of them are extensions to the test suite, to make sure that we cover weird corner cases between the MIME spec and this now-common form of header protection. As always, review, feedback, critique, and patches are welcome. Happy Hacking, --dkg