Bug: Unusable key

[gabriel rosenkoetter]

On Fri, Feb 06, 2004 at 08:50:38AM -0500, David Shaw wrote:
> 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.

90% of the people who see this for the first time will be seeing it
on a key that expired. Either a friend of theirs forgot to update
their expiration date, the user themselves didn't know they had
CREATED an expiration date, or they just need to do --recv-key to
see a new self-signature on the key.

Telling an experienced user "You may want to check keyid FOO" will
do much more for them. They'll say, "Oh, damn, I forgot to update my
key." Telling a new user to "You may want to check keid FOO" will
make them go, "Huh?" read the docs, understand what is meant by
"keyid", look at that keyid with gpg --list-keys... and see why it's
no longer valid.

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.

> 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.

> Sometimes giving more information leads to less clarity overall.

I believe you are flatly mistaken in this case.

> 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.

Date stamps are HUGELY relevant to the confused user issue precisely
here. Telling Werner that keyid 621CC013 has expired *immediately*
reminds him "Oh, damn, I forgot to update my key." Saying "the key
doesn't support encryption" forces him to go do the investigation
himself which you could very easily have just done for him because
you were looking at each of those keys. The utility of the date
stamp is that you can use it to tell which relevant subkey was
handled last by the owner of the key.

All of that aside... what's wrong with a six line error message?

What's the problem with saying all of those things all of the time?

(Ah, I read ahead and see that your answer will be "Nothing,
really.")

> 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.

I'm offering you a compromise: sufficient detail ordinarily, full detail
with --verbose. If you want to make the verbose version the default,
that'd be swell too.

> 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. ;^>

> That is not something I want to do unless there is a really good
> reason.

There's very obviously a really good reason. People are regularly
confused. But I don't think that point's in contention.

> 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

This seems perfectly reasonable to me.

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.)

> 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.

Consider only printing the last one under --quiet. (You do still
need to print *something* with --quiet, rather than fail silently, I
think.)

-- 
gabriel rosenkoetter
gr at eclipsed.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
Url : /pipermail/attachments/20040206/6cc16814/attachment.bin