Bug: Unusable key

[markus kampkötter]

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

what about an error-message like this:
"key bla unusable: for details look at manpages xy"
within the manual you could give a hint to this thread.
no need to change the code, not too big error msg, bigger manual :-/


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

thats the point: the experienced user doesn t want too detailed
information about things sHe already knows enough about (and worse: may
show up on a day to day use), and for the unexperienced user this
information is hardly helpfull, because you have to look up the details
anyway (probably in the manual).
 
> David

markus