From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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----- --=-=-=--