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 491736DE0B64 for ; Sat, 11 Nov 2017 19:51:29 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.05 X-Spam-Level: X-Spam-Status: No, score=-0.05 tagged_above=-999 required=5 tests=[AWL=-0.050] 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 vet-M0kRuse8 for ; Sat, 11 Nov 2017 19:51:27 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by arlo.cworth.org (Postfix) with ESMTP id 8F0726DE0B6D for ; Sat, 11 Nov 2017 19:51:27 -0800 (PST) Received: from fifthhorseman.net (dhcp-97f5.meeting.ietf.org [31.133.151.245]) by che.mayfirst.org (Postfix) with ESMTPSA id 4B451F99B; Sat, 11 Nov 2017 22:51:24 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id E6CD0211B6; Sun, 12 Nov 2017 11:51:14 +0800 (+08) From: Daniel Kahn Gillmor To: Jameson Graef Rollins , Notmuch Mail Subject: Re: Stashed session keys In-Reply-To: <87po8os887.fsf@ligo.caltech.edu> References: <20171025065203.24403-1-dkg@fifthhorseman.net> <87po8os887.fsf@ligo.caltech.edu> Date: Sun, 12 Nov 2017 11:51:11 +0800 Message-ID: <87tvy017f4.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.23 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, 12 Nov 2017 03:51:29 -0000 --=-=-= Content-Type: text/plain On Sat 2017-11-11 15:31:36 -0800, Jameson Graef Rollins wrote: > I have reviewed and tested this series, and it seems solidly > implemented and very well motivated. I have been using it regularly > for a couple weeks now and have found no issues with it's usage, and > have noticed the considerable speed up when viewing encrypted threads > (as much as x8 for show on a thread of just 8 encrypted messages). I > fully support it's integration unconditionally. thanks for the review, the testing, and the reportback. I'm glad to hear that it's giving you the same sort of speedups that it gives me. > Daniel likes to think of this in terms of being able to "delete" > encrypted messages in the wild (via deletion of the original > encryption key) whereas I like to think of it in terms of preserving > access to received encrypted messages after key rotation. Both > benefits hold, though, obviously. yes, these are different ways of looking at the same key management strategy. > I think these policies cover all potential use cases that I can see. > However, there will need to be further work on the UX to make things > flow more smoothly. Agreed. The goal of this series is to provide the framework that can be used to build smoother UX, but it doesn't get all the way to providing the smoothest possible UX. Such is the nature of toolkit development. > I haven't decided what's the best way to do that yet, but something > like the following happening automatically at inbox view might do the > trick: > > notmuch reindex --try-decrypt=true (tag:inbox AND tag:encrypted) This seems like a reasonable way to ensure that your long-term, personal secret keys only get accessed when you are interactively working with your mail user agent. You might be able to target the reindex even more narrowly by adding something like "AND not property:index-decryption=success" > Finally, I think it would be worthwhile to resolve the disparity between > the usage of "decrypt" and "try-decrypt" in the CLI and config options. > I'm not sure why we're using different terms in different contexts, even > though the meanings are essentially the same. A follow-up patch series > changing "try-decrypt" -> "decrypt" would probably be in order. If this series lands, i'd be happy to supply such an term-normalizing series for subsequent consideration. If people feel that this term normalization is the main blocker to landing this series, i could try to rebase it with a different UI terms, but rebasing the series for this change feels like busy-work to me (and would be more effort than a simple normalization patch on top). i'd rather spend my limited notmuch hacking+reviewing time providing useful features. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOCdgUepHf6PklTkyFJitxsGSMjcFAloHxS8ACgkQFJitxsGS MjfuphAAg077D1IfDNuGrxv9Vumo0BIv3dBAu7sx69uzJ0mhqNuppBxYM74gr3So qaRTjReo6hk4V/hJdBwLPSyEb/gJlQurUCg8Rf6at+xrG7pu9W18Xi49sbsV8CYD HiJFPNwVz0BAxgc8x4H7KFkKsW6OaV1sMUEBFROL5sVFDwgJkNpGzEQeelgjlvGJ mwzD5qHxa7LwFzs+fOMfuDnTs/FqyhEDj5NE0UUKe8t/RlaniSeAepkI+gHpGXk1 S75+j9IOs1lKI4V4CQ3GALteHvjQkmnnNwF4idWmAyuCP4nRZTxtCjiONDbGr/Br R7E/k66hvwm4NiRgN0joirmCz7RbmV4c5NBfN1KZD/2YvvOBbSkPWFgpUFE97h36 pN4oLnES1LG9L0PRW3OtYJVQOo1CBuhRKHoornHkrywaK42KY1FVDuqZxSS/Ob0x eXFYdglFTJ26ghSgpQkltTCKR68TQ+k5ht/4cqY1+qYjFSlgigLu8M3HMyOv/vLc HT79eMHeMmWMiKybkEoANgSaSE36bE0R0ym+VJMmcLNkGp5sRV/zaHiKy4S+B/fD LhKI0gzRAMu5YEfIv3v3iS8cKRXV8NZriVrcPiDnWjxNBmby1SYItc5QpdkrRLz5 rpRTT7Vs96lqkxu7sm5BjgsfE7iIR3jQlvBa/SifcSdSDIGj/RU= =ZYJc -----END PGP SIGNATURE----- --=-=-=--