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 5C87B6DE0B27 for ; Thu, 10 May 2018 23:58:16 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[AWL=-0.018, RCVD_IN_DNSWL_NONE=-0.0001] 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 gwVcch8XaQgs for ; Thu, 10 May 2018 23:58:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTPS id 5270E6DE0B22 for ; Thu, 10 May 2018 23:58:12 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) (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 A925EF9A3 for ; Fri, 11 May 2018 02:58:08 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 56B87203C5; Fri, 11 May 2018 02:58:03 -0400 (EDT) From: Daniel Kahn Gillmor To: Notmuch Mail Subject: v3: notmuch show --decrypt=stash Date: Fri, 11 May 2018 02:57:51 -0400 Message-Id: <20180511065759.8556-1-dkg@fifthhorseman.net> X-Mailer: git-send-email 2.17.0 X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.26 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: Fri, 11 May 2018 06:58:16 -0000 This is an improvement on the series most recently sent in id:20180110001228.2211-1-dkg@fifthhorseman.net (with the initial version in id:20171212025225.11854-1-dkg@fifthhorseman.net). The differences between this and v2 of this series are cleanup and readability improvements suggested by David Bremner. This series allows "notmuch show" to index the cleartext and stash the session keys of an encrypted message while displaying it. Background ---------- As of notmuch 0.26, cleartext indexing and session-keys make working with encrypted e-mail significantly easier in notmuch. However, the underlying requirement is that at the time of message ingestion (and "notmuch new" in particular), the user is likely to have access to their long-term secret keys. In practice, many people using GnuPG today have their secret keys locked behind a passphrase, or on a smartcard, and also run "notmuch new" in some sort of scheduled, backgrounded process. The result is that for users with this workflow, GnuPG prompts for their passphrase (or wants to make use of their smartcard) at unpredictable times, depending on when their mail delivery happens, and on how many encrypted messages they receive. This is both unfriendly and bad for security (we should not train users to approve random prompts for secret key access when nothing they're doing interactively seems to warrant it). Outline ------- For a friendlier experience, some users may prefer incoming encrypted mail to stay in their inbox *without* being decrypted, until they choose to look at it. At the moment that they're looking at it, their MUA is in the foreground and they're interacting with it, so being prompted for their password or smartcard interactively makes sense at that time. This series makes it possible for this interaction to to actually decrypt the message, index it, and stash any session keys the first time the user interacts with the message through "notmuch show". This is not a workflow that every MUA will choose to use (e.g. users whose decryption-capable secret key is already cheaply available without hassling the user at "notmuch new" shouldn't use it), but it is a sensible workflow for some users that notmuch should support. Furthermore, it is a more efficient use of secret key material -- a user that wants to stash session keys of a message, but whose long-term decryption secret key is on a smartcard should only be obliged to trigger the smartcard once per message, ever. Implementation details ---------------------- The most controversial part of this series is that it makes "notmuch show" potentially not a read-only operation on the database. This is a tradeoff that the users of this workflow will need to consider, since they are explicitly asking "notmuch show" to potentially modify their index. Note that i've made this R/O-to-R/W switch fairly coarse. If the user requests --decrypt=stash, then "notmuch show" will operate on a read/write database, regardless of whether the message is actually encrypted. I used this coarse approach because i couldn't figure out a safe way to reopen an existing read-only database in read-write mode. If someone more clever with Xapian than me wants to suggest a way to do this in a more fine-grained fashion, i'd welcome patches or pointers. That said, if users don't like the idea of "notmuch show" using the db read/write, they can also just not use --decrypt=stash :) Let me know if you see anything else that could be improved here! --dkg