Bug: Unusable key

gabriel rosenkoetter gr at eclipsed.net
Fri Feb 6 07:20:54 CET 2004


On Fri, Feb 06, 2004 at 12:05:24AM -0500, David Shaw wrote:
> I think that's more confusing than helpful.  "such-and-such skipped:
> the most recent subkey was revoked or expired".

"such-and-such skipped: no useable public key. (You might want to
check on <keyid>, which {expired,was revoked} on <date>.)"

I think you're making this whole UI thing harder and more formal
than it has to be. :^>

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

> > As soon as you've got a useable one, you're done, and you don't
> > produce any error output, and that's BY FAR the more common case,
> > isn't it?
> I'm not concerned about the successful case.  There is already a good
> answer for that (say nothing).  I don't agree with the argument that
> an error message doesn't matter because it isn't the common case.

My argument wasn't that, it was that tersity isn't very important
because the average user will see this message only very seldomly.
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.

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.

Is what I'm suggesting really that far out in left field?

-- 
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/9374d67e/attachment.bin


More information about the Gnupg-users mailing list