Bug: Unusable key

[David Shaw]

On Fri, Feb 06, 2004 at 07:20:54AM -0500, gabriel rosenkoetter wrote:
> On Fri, Feb 06, 2004 at 12:05:24AM -0500, David Shaw wrote:

> > relevant, as stated by the error message, which isn't true.  Worse
> > again, there doesn't have to be SUBkeys involved in the first place.
> > V3 keys don't have them, and V4 keys can be sign+encrypt.
> 
> Okay, so just tell me the keyid, what's wrong with it, and when it
> went wrong. If I ask for verbosity, tell me about all of them.
> ("Can't use <keyid> because it {expired,was revoked} on <date>.",
> one per unuseable key, then the above again.)
> 
> > These are really just trading something terse and mostly unhelpful
> > (but true) for something else terse, mostly unhelpful, but true.
> 
> Is what I suggest above not helpful, true, and insignificantly less
> terse?

It's helpful, true, and less terse - it's also not the whole story.
True that the user can't use <keyid>... but our poor user also can't
use <keyid[1]> (revoked a year ago) <keyid[2]> (it expired a month
before <keyid>) and they don't understand WHY.  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?

Sometimes giving more information leads to less clarity overall.

> The very fact that we will see it seldomly means that it should be
> at least slightly more verbose and specific so that we understand
> what it means. I see short, useless error messages out of, say,
> Veritas Volume Manager maybe once a year. I know I know what they
> mean, but I have to go use Google to remember what I did the last
> time to fix it. It's really irritating to have to check
> documentation when even the littlest bit more information presented
> by the application would have meant I didn't need to.
> 
> > encryption" or "is expired", or "is revoked".  If the user asks to use
> > "the key" as a whole, then the unfortunate fact is that there are a
> > huge number of possible reasons why a given public key might be
> > "unusable".
> 
> I think you're overstating the quantity possible reasons on the
> average key (would you care to present a sample key on the
> keyservers that, were its most current signing subkey revoked or
> expired, would present a "huge number", please?), and I think you're
> ignoring the usefulness of the date stamps that are absolutely
> required by the protocol.

Not a huge number of subkeys - a huge number of reasons.  Take
Werner's key 621CC013 as a good example.  It has two expired subkeys,
one revoked subkey, and one good subkey.  Let's say that the good one
expired, so the reasons 621CC013 would become unusable for encryption
are:

1) ADF6A6E1 is expired
2) B5A18FF4 is expired
3) B5A18FF4 is Elgamal type 20
4) B5A18FF4 is revoked
5) 23D2A63D is expired
6) 70E37CCD is expired
7) 621CC013 doesn't support encryption

#2 and #4 can be collapsed into one item since it was revoked before
it expired, so ditch #2.  That leaves 5 reasons.

Date stamps are not really useful here since it's not a correctness
issue - it's a confused user issue.

> I think you're worrying about irritating a couple of very
> experienced users by giving them a slightly longer error message
> when you should be concerned about confusing the far greater number
> of less-experienced users with an insufficiently specific error
> message.

No, you misunderstand my concern.  I have no problem at all in giving
a longer error message.  I don't believe that terse is good, nor do I
like the current error message (the fact that it comes up on this
mailing list every month is a pretty good indication that it's not
clear enough).  My concern is that a longer error message tell the
whole and complete story, which causes a counter-concern that the
message will be too large.

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.
That is not something I want to do unless there is a really good
reason.

So - given that I want to have a better error message here, and given
that I have to dig into and make a number of changes in (for example)
the key retrieval functions to support giving a more informative error
messsage, I want the best possible bang for my buck.  I want the code
to be reusable, and I want a REALLY DARN GOOD error message ;)

The suggestion that I currently like the best, despite my concern
about what will happen as keys age and gain more subkeys, is to just
list each key and the reason why it wasn't accepted.  Using the
hypothetical expired key of Werner's:

gpg: unable to encrypt to subkey ADF6A6E1: expired 2002-11-01
gpg: unable to encrypt to subkey B5A18FF4: revoked 1999-11-12
gpg: unable to encrypt to subkey 23D2A63D: expired 2003-12-31
gpg: unable to encrypt to subkey 70E37CCD: expired 2004-02-06

That says everything, it's clear as a bell, and if that lists gets too
long over time... well, I'm willing to change things then to perhaps
list only the top 4.

David
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 330 bytes
Desc: not available
Url : /pipermail/attachments/20040206/ad4e85b7/attachment.bin