new "crypto" branch providing full PGP/MIME support

[micah anderson]

On Thu, 03 Feb 2011 14:52:01 -0500, Daniel Kahn Gillmor <dkg at 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
> 
> 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"
> 
> 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?
> 
> Short keyIDs are easily spoofable; believing anything based on a matched
> short keyID is a mistake. 

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. 

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.
> 
> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20110204/d3180abd/attachment.pgp>