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 6D2CA6DE025B for ; Tue, 19 Jun 2018 13:18:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -1.667 X-Spam-Level: X-Spam-Status: No, score=-1.667 tagged_above=-999 required=5 tests=[AWL=-0.330, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.972, T_RP_MATCHES_RCVD=-0.01] 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 9llZ7_TybI_4 for ; Tue, 19 Jun 2018 13:18:04 -0700 (PDT) Received: from outgoing-mail.its.caltech.edu (outgoing-mail.its.caltech.edu [131.215.239.19]) by arlo.cworth.org (Postfix) with ESMTPS id 1947A6DE0259 for ; Tue, 19 Jun 2018 13:18:04 -0700 (PDT) Received: from smtp01.caltech.edu (localhost [127.0.0.1]) by smtp01.caltech.edu (Postfix) with ESMTP id 808EAA025E; Tue, 19 Jun 2018 13:18:03 -0700 (PDT) X-Spam-Scanned: at Caltech-IMSS on smtp01.caltech.edu by amavisd-new Received: from finestructure.net (gwave-71.ligo.caltech.edu [131.215.114.71]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: jrollins) by smtp-server.its.caltech.edu (Postfix) with ESMTPSA id 1C78FA0178; Tue, 19 Jun 2018 13:18:03 -0700 (PDT) Received: by finestructure.net (Postfix, from userid 1000) id E7C906198E; Tue, 19 Jun 2018 13:18:02 -0700 (PDT) From: Jameson Graef Rollins To: Daniel Kahn Gillmor , notmuch@notmuchmail.org Subject: Re: [PATCH] emacs: new crypto customization variable to control stashing of encryption session keys In-Reply-To: <87y3fa20f7.fsf@fifthhorseman.net> References: <20180618003138.2894-1-jrollins@finestructure.net> <20180619152012.29128-1-jrollins@finestructure.net> <87y3fa20f7.fsf@fifthhorseman.net> User-Agent: Notmuch/0.27~rc1+20~g2204192 (https://notmuchmail.org) Emacs/25.2.1 (x86_64-pc-linux-gnu) Date: Tue, 19 Jun 2018 13:18:00 -0700 Message-ID: <87vaaejzt3.fsf@ligo.caltech.edu> 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.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: Tue, 19 Jun 2018 20:18:05 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Tue, Jun 19 2018, Daniel Kahn Gillmor wrote: > This is looking good to me, thanks! > > two more bits of nit-pickery below: > > On Tue 2018-06-19 08:20:12 -0700, Jameson Graef Rollins wrote: >> +(defcustom notmuch-show-stash-session-keys nil >> + "Should session keys be stashed when decrypting messages for display? >> + >> +If this variable is non-nil session keys recovered while >> +decrypting messages for display will be stored in the database. >> +See description of --decrypt option in notmuch-show(1) for more >> +information. > > do we want to include a warning here about the security of the index? > setting this value to true not only stashes the session keys, but it > also indexes the cleartext. at the moment we're not directing people to > the same kind of warnings ("Be aware that the index=E2=80=A6 DO NOT USE = =E2=80=A6 > without considering the security of your index.") that are present > already in notmuch-reindex(1) and notmuch-new(1) and notmuch-insert(1). > Perhaps notmuch-show(1) needs the same boilerplate warning, and we could > replicate some short version of it here too? I was wondering if it would make sense to have a separate man page for describing all the intricacies of notmuch's crypto functionality, i.e. notmuch-crypto(7). There's going to be a lot of redundancy/boilerplate in all the different man pages, and it seems like it would be useful to put it all in one place and just reference it from all the others. This could also be a good place to describe how protected headers are handled, and autocrypt once we finally get around to implementing it. >> +NOTE: Stashing encryption session keys requires opening the >> +notmuch database in read/write mode, which is not normally done > > i'd say "not otherwise done" instead of "not normally done", since we > don't want to claim that people who use this feature aren't "normal" :) But the claim wouldn't not be true! I'll push another (five copies of a new) version. jamie. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEtl0IW5QRe4ExYLZZ7TTOq+J7qrwFAlspZPgACgkQ7TTOq+J7 qrxzXw//TnFAQb8BZLi6ZN8kLxPwnuti2RCdt7XNCptivn3S1G7YXvmFmSN9kb0C VntdtpHnEIyeDR9vV2DR9OALpHJgQ5xigTYhVHO7YH9/Q99rXK6efBolFD86iyI9 9MjOfkfKaMJhF3Ob91FIsAN6/AvLL6KaczQoPudZeqxBtjTPdm4YNwD9L0Y2mKqg lThbgkfj4OnM18+wVjiQqeDRZa1/Bh0LgFFX7DluAHWa4Rbhodo6gzVflVyqW4oi RqmSDJjoVuuYJCA6pFFzisCCr+OL+mu3Q+iR1J6XwcVUcMV94aWcArtaXJUmYgZo VoZpmVHbLadlDLi8qNgcQaQ/2mvJ5VjvARJn8jLUIvJHud7yDVmMhoHjprg/Bos7 Jo2Rf+pgUlKNKP9J5xb7v9sp+MRYQbW2/IN3H7ZoERZtO9izO9VcrmT/Opvo/8Km ryq9lB/wFkBBf7joC1cUQBom8YilaTIPwnIkOcybGfnYM2ZIBHdxaGlqyr6rb5Wo qDca3KoJfE02g89XUbowbC1XdDCroNhH5EhXCCJ3GH63QbhGCfCdm1lTrBs85ouP KyfOm/WPaXhpUvtxibctmMv3FaDaDJfwa4rJp1p6o8+EHIFplL1HD8Ox1KKovq4f VxNuZ0BtLQAF0vOIuwziLGVRqXZFgcf9BmNDjRSCbXgWdcEE22Q= =tLOD -----END PGP SIGNATURE----- --=-=-=--