Bug: Unusable key

[David Shaw]

On Fri, Feb 06, 2004 at 01:10:36PM -0500, gabriel rosenkoetter wrote:

> In both cases, telling them about the most recently invalidated key
> is all you need in a short form, as long as you also provide a "this
> key is bad, and this key is bad, and hey, all your keys are bad"
> output in a verbose form.  This is really just not as complicated as
> you're trying to make it.

I strongly disagree.  Human interface factors are pretty darn crucial
in general, and much more so for a security application.  GnuPG is not
supposed to be used solely by crypto fans.  Open source software has a
bad reputation for being written by geeks for geeks.  I believe in the
benefits of crypto, so that can't fly here.  I want as few barriers as
possible to people using it.

This is why GnuPG gives an error "encrypting a message in --pgp2 mode
requires the IDEA cipher" rather than "cipher 1 unavailable".

> > At the same time, by
> > not mentioning the other subkeys, the user wonders those other keyids
> > weren't mentioned.  Clearly they exist - he can use --list-keys and
> > see them!  What's going on here?
> 
> No, a user that can't figure out that the other keys are expired
> doesn't even KNOW to look at the other keys.

That's absurd.  There are certainly users who know how to type
--list-keys (which is the first example given in every single "how to
use GnuPG" document I've ever seen), but yet don't know that PART of a
key can expire without affecting the rest of the key.  How many people
on this list right now don't know that?

> > The problem here is that given the code in that particular area of
> > GnuPG, changing the error string is easy, but giving more information
> > is complex and touches a good number of other places in the code.
> 
> Oh, so this is a "But that's work!" response to a bug report. ;^>

Pretty straightforward cost/benefit calculation.  The cost is
relatively high for this one given how the key selection code works.
If the benefit isn't, then it's not worth it.  Without that
calculation, then every feature that anyone wants, however ill
advised, goes into the code and the code becomes unreadable - and
unverifiable - spaghetti.  Spaghetti is not what you want to see in a
security application.

I ask a cost/benefit question of myself before making any change to
GnuPG.  To do otherwise would be irresponsible.  Generally, the
conversation is within my head and lasts a few minutes.

That doesn't mean that I'm willing to run the risk of stagnation
either.  There is a development branch of GnuPG (1.3.x) where the bar
for changes is set pretty darn low.  This will become GnuPG 1.4
eventually.

Like I said before (and you snipped out), I think the benefit here
justifies the cost, but given the cost, I want a pretty darn good
benefit.  And if that means I need to think about 7 different ways to
do it, then I'm going to think about 7 different ways to do it before
picking the best one.  Usually that's a short process, when there are
no mailing lists involved.

> I think that, in general, GnuPG errs on the side of too little
> output already. (The default --list-key format is horribly obtuse
> to the new user, for instance.)

Suggest an alternative, and say why it is better.  Format stuff can be
cheap to change, as I've already "invested" in the architecture to
allow users to customize formats to some degree.  Have you looked at
the format changes in 1.3.x?

David