Thanks for reporting this. This is a bug. BTW, do you have an example of a
short keyid that is ambiguous?

a couple of examples I'm aware of:
A56E15A3
70096AD1

Thank you

I don't consider this a bug unless you specify the key by fingerprint. Keyids
are by design ambigious and --delete-key takes care not to accidently delete a
key. Consider that --recv-key retruned a dup in the keyid of your key. The
--delete-key would then delete your key as well.

Yup, without short ids being ambiguous, this problem wouldn't be here.

I think it'd be ok with me as well to ignore this issue, IF users were educated
to always use fingerprints instead of the keyid, but as of now unfortunately
most people still seem to prefer them.

I think that the gpg --list-keys output is supposed to be consumed by humans,
not automated tools, right? If so, it might be helpful to switch its default
representation to show fingerprints and not keyids. (Also, I find it a bit
confusing that the default fingerprint representation for gpg, that is: 4
hexdigits separated by spaces is not supported by other tools like apt-key, but
I guess this should be raised as an issue to them).

Moreover, --delete-key always prompt before deleting, so prompting twice
wouldn't be risky... and I just realized from the gpg manual, for --delete-key:

"Remove key from the public keyring. In batch mode either --yes is required or
the key must be specified by fingerprint. This is a safeguard against
accidental deletion of multiple keys."

So, apparently, according to the manpage, --delete-key is supposed to delete
multiple keys.

gpg2 --help instead shows a --delete-keyS command... but that command
doesn't delete multiple ambiguous keys either.

I framed this bug report with the user expectations for an invariant, not as a
bug of the --delete-key or --recv-key command, since it could be fixed
either way, so I don't have a strong opinion in the direction to take from here

I'm sorry, but this is a bug. --delete-key needs to indicate to the user that
the key specification is ambiguous. Further, in non-batch mode, it should
iterate over all of the keys that match the specification and no such take the
first one.

Here's is the status quo:

$ gpg2 --keyserver pool.sks-keyservers.net --recv-key A56E15A3

gpg: key A56E15A3: public key "Hubert Figuiere <hub@figuiere.net>" imported

gpg: key A56E15A3: public key "Pedro R. Fernandez (GNU/Linux User #000.204.555

http://counter.li.org/) <prafer@eresmas.com>" imported

  $ gpg2 --keyserver pool.sks-keyservers.net --delete-key A56E15A3
  pub  dsa1024/A56E15A3 2002-01-30 Hubert Figuiere <hub@figuiere.net>

  Delete this key from the keyring? (y/N) n
  $ gpg2 --keyserver pool.sks-keyservers.net --delete-key A56E15A3
  gpg (GnuPG) 2.1.10-beta159; Copyright (C) 2015 Free Software Foundation, Inc.
  pub  dsa1024/A56E15A3 2002-01-30 Hubert Figuiere <hub@figuiere.net>
  
  Delete this key from the keyring? (y/N) y

  $ gpg2 --keyserver pool.sks-keyservers.net --recv-key A56E15A3
  gpg: key A56E15A3: public key "Hubert Figuiere <hub@figuiere.net>" imported
  gpg: key A56E15A3: "Pedro R. Fernandez (GNU/Linux User #000.204.555

http://counter.li.org/) <prafer@eresmas.com>" not changed

gpg: Total number processed: 2
gpg:               imported: 1
gpg:              unchanged: 1
$ gpg2 --batch --delete-key A56E15A3
gpg: can't do this in batch mode without "--yes"
gpg: (unless you specify the key by fingerprint)
$ gpg2 --yes --batch --delete-key A56E15A3
$ gpg2 -k A56E15A3
pub   dsa1024/A56E15A3 2002-01-30
uid         [ unknown] Hubert Figuiere <hub@figuiere.net>
uid         [ unknown] Hubert Figuiere <hub@mozilla.com>
uid         [ unknown] Hubert Figuiere <hub@abisource.com>
uid         [ unknown] Hubert Figuiere <hfiguiere@teaser.fr>
sub   elg2048/392105DE 2002-01-30
sub   elg2048/DFB0629B 2005-09-21

neal: What you describe are two a different things/bugs.

1. Indicating that a specification is ambigious. We do this at other places as well

2. Continue to show (with -k) or ask (with --delete-key) the other matching keys.

For the later I don't think that there is a need to do this with --delete-key
because we would have already printed that the specification is ambigious.
However a "gpg -k shortkeyid" should list all matching short keyids. A quick
test with:

0F26563A76B8337A
D1EC50AA76B8337A

shows that this is not the case. Note that we need to take care when modifiying
--delete-key. Not all programs using this are well written but implicity assume
the current behavious. And unfortunately many authors do not use --with-colons
and rely on the human output. Not deleting is better than accidently deleting
something.

werner: Are you suggesting that there are programs that use an ambiguous
specification in order to delete just one key? I'm trying to imagine how this
is not undesirable behavior. Do you have any examples of this?

I have no examples. However I have seen too many scripts using gpg in often
very strange ways. Thus I always hesitate to change anything even if it is
clearly stated that this is not a documented interface.

People often hack something, it works for them, and they continue with other
work. Years later things break and nobody is left knowing what the code
actually does. Not good but that is how things are.