From 41a106f381201a2ac68b22dc69652504a0c5d2ae Mon Sep 17 00:00:00 2001 From: micah anderson Date: Sat, 5 Feb 2011 11:59:43 +1900 Subject: [PATCH] Re: new "crypto" branch providing full PGP/MIME support --- 00/604f44e44d156528a8c3c3824d93032546fc27 | 170 ++++++++++++++++++++++ 1 file changed, 170 insertions(+) create mode 100644 00/604f44e44d156528a8c3c3824d93032546fc27 diff --git a/00/604f44e44d156528a8c3c3824d93032546fc27 b/00/604f44e44d156528a8c3c3824d93032546fc27 new file mode 100644 index 000000000..7d1c71c7f --- /dev/null +++ b/00/604f44e44d156528a8c3c3824d93032546fc27 @@ -0,0 +1,170 @@ +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 C62AE431FB6 + for ; Fri, 4 Feb 2011 08:59:48 -0800 (PST) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.689 +X-Spam-Level: +X-Spam-Status: No, score=-0.689 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_LOW=-0.7, T_MIME_NO_TEXT=0.01, + UNPARSEABLE_RELAY=0.001] 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 9rIpO-OoAIY6 for ; + Fri, 4 Feb 2011 08:59:48 -0800 (PST) +Received: from mx1.riseup.net (mx1.riseup.net [204.13.164.18]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id F3D6B431FB5 + for ; Fri, 4 Feb 2011 08:59:47 -0800 (PST) +Received: from tern.riseup.net (tern-pn.riseup.net [10.0.1.12]) + (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) + (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (verified OK)) + by mx1.riseup.net (Postfix) with ESMTPS id 137BF25F5F7; + Fri, 4 Feb 2011 08:59:47 -0800 (PST) +Received: from [127.0.0.1] (localhost [127.0.0.1]) + (Authenticated sender: micah@tern.riseup.net) + with ESMTPSA id 5144B14C16C +Received: by algae (Postfix, from userid 1000) + id B655F41A77; Fri, 4 Feb 2011 11:59:44 -0500 (EST) +From: micah anderson +To: Daniel Kahn Gillmor , + notmuch +Subject: Re: new "crypto" branch providing full PGP/MIME support +In-Reply-To: <4D4B0761.7040603@fifthhorseman.net> +References: <4CF15D67.1070904@fifthhorseman.net> + <87aak08fu8.fsf@servo.finestructure.net> + <87fwsf9mip.fsf@servo.finestructure.net> + <87tygl29vu.fsf@servo.finestructure.net> + <87hbclkrvh.fsf@algae.riseup.net> + <4D4B0761.7040603@fifthhorseman.net> +User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1 + (i486-pc-linux-gnu) +Date: Fri, 04 Feb 2011 11:59:43 -0500 +Message-ID: <87r5bn68hs.fsf@algae.riseup.net> +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha512; protocol="application/pgp-signature" +X-Virus-Scanned: clamav-milter 0.96.5 at mx1 +X-Virus-Status: Clean +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: Fri, 04 Feb 2011 16:59:49 -0000 + +--=-=-= +Content-Transfer-Encoding: quoted-printable + +On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor wrote: + +> On 02/03/2011 11:25 AM, micah anderson wrote: +> > 1. I personally think notmuch-show-process-pgpmime should default to +> > true +>=20 +> note that with it set to false, you can still M-RET (instead of RET) on +> an item in the summary window to have it set for that particular view. + +Yes, that is true. However, I still think the default should be +on. Especially considering all three people (myself included) who I've +seen try this have been puzzled by why it wasn't working and had to be +told that they needed to turn it on. + +> > 3. i'm not sure expired/revoked keys are handled properly - tested on a +> > message that was encrypted by a key that was revoked and got "End of +> > file during parsing" +>=20 +> when you say "encrypted by" do you mean "encrypted to"? do you have +> access to the corresponding secret key? + +If I open a message that was sent to me and was encrypted by the sender +using a key that they have since revoked, or has expired, I saw this. + +> > 5. unknown keys are represented in a long format, +> > eg. '0x5585F58CC827A062' when most tools represent them just with their +> > shortened keyid (in this case this one would be: 0xC827A062), is there a +> > particular reason for this? +>=20 +> Short keyIDs are easily spoofable; believing anything based on a matched +> short keyID is a mistake.=20 + +Most humans I know reference their key by the keyid, where keyid means +the 8 character representation of their key. When they need to ensure +that their key is not being spoofed they either rely on the tools to do +cryptographic verification, or inspect the fingerprint. I dont think +moving towards using a longer format of the keyid helps here. The key is +unknown, and to get it known requires going through a key signing +process, or fingerprint verification, which isn't aided by having a +longer form keyid.=20 + +If I am presented with a short form keyid, and I go and try and receive +that key from the keyservers and then I am presented with two different +options, then I'm going to inspect the two and determine then which one +is the right one. I dont need to front-load that knowledge in the +interface. + +> > I recognize some people's keyids in the +> > short form, but do not in the longform. +>=20 +> You can derive the short form from the long form by ignoring +> everything but the last 8 hex characters. + +Yes, I know that, but my brain parser looks at '0x5585F58CC827A062' and +has to squint to try and ignore the last 8 characters. In fact, its +often quicker for me to use my cursor to go up there and count backwards +8 characters and then hit a space so I can visually separate it. Visual +interface parse failure with long form. + +> But if you actually recognize the short form, i'd expect you to have +> the relevant key in your keyring; + +Not always true. In fact the parse error I was discussing above was +about a key I used to use, but have removed from my keyring, and my +secret keyring. In the long form, I did *not* recognize it. If it were +simply 1CF2D62A I would have instantly recognized it as my old key that +I've revoked. + +> is this really a use case worth bothering with? + +No. + +> do you have a suggestion for how you think it should behave +> differently? + +I think my suggestion was already made: short form. + +m + +--=-=-= +Content-Type: application/pgp-signature + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1.4.10 (GNU/Linux) + +iQIcBAEBCgAGBQJNTDCAAAoJEIy/mjIoYaeQIysP/j6/0NGMzRqxE5qU207RK3uP +eZ012HH0IausbabqeB2WhgsOffTuCMoZwPUHNK3MNvKfifJyVSPaRFiYu6PheNpS +g7q26WCgJHcxLv2UqIZvOBenr79NFt1g18GPc8huVFsNozoIexje/d2IGjVF+tDw +IbM4FnR5OcgZhhGtPMNBFxn9PKFyZ29Kr67/3bYQ7BVwUDMpI9XIVGszQLWH6sew +JQ4KtvzhnRmnBuNdbz2KmSPHCocIAz/+ihXzKZpn3hnjTyZBJRoo1goThq3t8cwc +o0hKr+mCiilAlQn6dkVBXsw/2vGXgipV8Hr6FEcwuwZgilEgDuOIqEW9QjPRXVRz +O75IZ/tKYxqhps/F8a0AQPd+DwzXxLbw5y1FhUHH+fpMytr45WRVx7puyYAygSN7 +q7waVL/iYW+9FLVSy171eP85IvW6v9eyW6z6rDtQrb3PFFQ9u5e0e0KsTNRBy6h6 +1NVVOUJ+COTAaKp6BHFUoM5zmxi+nLBc8eYV8TDXoq77j9pA0qHNKcKj+ITSHPy/ +P19gAlAS+LLrMRBvawzx0G31Thl+ouq4xVqG4tuSw+6WWFpa6Wk+w3ylHMhF7YUz +b2FoudBMvPdGZ2Z7Dsw6UsxzS13D/03fZdJ9VO15IFerkrxbvSPf/uo1uPJ/GnBd +7ycOq6PmdT0v4Pr7hKIw +=w0qR +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2