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