Handling ambiguous key specifications

[W Lewis]

I've been using 1.0.6 recently and have noticed that it doesn't handle
ambiguous key specifications very well. For example, if I attempt to
encrypt to <bob at example.com>, and Bob has several keys of various sorts,
gpg will just pick one of them (presumably the first one in the ring:
effectively, at random)  without asking or warning me. I think this is
never the correct behavior.  If a user specifies a key --- either as a
text/address match, or a keyID or any kind --- it might be used in several
situations:

A) If it's used to specify something that can only accept one key (eg,
specifying a signing key for a message), then gnupg should either fail
with an error, or (if in an interactive situation) ask the user to clarify
their choice.

B) If it's used to specify something which *can* take several keys, but
which could result in an insecure operation (eg. encrypting to all
bob at example.com keys), it should either fail or ask for clarification.
The user may elect to specify that all matching keys should be used, of
course.

C) If it's safe (e.g. listing keys or exporting keys), then it makes sense
for gpg to go ahead and perform the operation on all keys matching the
user's specification.

It seems to me that it should be fairly straightforward to put routines
for these situations in getkey.c and make the rest of gpg use these
instead of e.g. get_pubkey_byname() directly. Or perhaps it would be
better to enhance build_pk_list(). In any case, I'll give this a whack in
a few days unless someone thinks it's a bad idea.

Wim.