From: micah anderson <micah@riseup.net>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>,
	notmuch <notmuch@notmuchmail.org>
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"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor <dkg@fifthhorseman.=
net> 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-----
--=-=-=--