Agreed.

D106: 719_0001-gpg-Check-for-ambiguous-or-non-matching-key-specs.patch

The following patch adds checks for --default-key, --local-user and --remote-user.

Check that any user id specifications passed to --local-user
and --remote-user correspond to exactly 1 user. Check that any user
id specifications passed to --default-key correspond to at most 1
user. Warn if any user id specifications passed to --local-user or
--default-user are possible ambiguous (are not specified by long keyid
or fingerprint).

$ gpg2 -s -a -r testing
gpg: WARNING: recipients (-r) given without using public key encryption
gpg: Error: the key specification 'testing' is ambiguous (passed to --encrypt-to).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.
$ gpg2 -s -a --local-user testing
gpg: Warning: value 'testing' for --local-user should be a long keyid or a
fingerprint.
gpg: Error: the key specification 'testing' is ambiguous (passed to --local-user).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.
$ gpg2 -s -a --default-key testing
gpg: Warning: value 'testing' for --default-key should be a long keyid or a
fingerprint.
gpg: Error: the key specification 'testing' is ambiguous (passed to --default-key).
gpg: 'testing' matches at least: 362D3527F53AAD1971AAFDE658859975EE37CF96 and
439D954F18F79CC4F71BED91CACED996BC15C85A.

Some comments:

• Always checking this _might_ slow down things. Let's wait for user response.

• Please do not die in that function. We may want to use it a other places too (server mode). Better return an error (NULL) and let the caller decide what to do.

• The strings should be changed to ease translation: For example put the second part into its own message: log_info ("(check argument of option '%s')\n", "--local-user");

• When you say let's wait, what do you mean? In particular, how are we going to

get a user response without checking the code in?

• Ok. I will return an error code.

• I already do this, e.g.:

log_error (_("no such key corresponding to %s (passed to %s)\n"),

t->d, option);

With 'wait' I mean: Push, release, wait for complaints.

log_error (_("no such key corresponding to: %s\n"),t->d)
if (!opt.quiet)

  log_info ("(check argument of option '%s')\n", option);

However, we need to check all error messages to make sure they use a common
scheme. For example at some places we use

key 123445567: This is is not usable

(commit e8c53fc was for master)

This introduces a regression. I had to revert this commit to be able to keep on
using gpg in my configuration. A description of the problem can be found at:
https://lists.gnupg.org/pipermail/gnupg-devel/2015-November/030549.html

I've fixed the problem that Niibe reported in 7546e81.

My problem was a different one. Here is what I wrote to gnupg-devel:

$ ../g10/gpg2 -vsbau 0xE3FDFF218E45B72B </etc/motd >/dev/null

[...]

gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.

gpg: (check argument of option '--local-user')

gpg: error reading key block for '0xE3FDFF218E45B72B': Unknown system error.

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

gpg: Error: the key specification '1E42B367' is ambiguous.
gpg: (check argument of option '--default-key')
gpg: error reading key block for '1E42B367': Unknown system error.
gpg: writing to stdout
gpg: EDDSA/SHA256 signature from: "E3FDFF218E45B72B Werner Koch (wheatstone

commit signing)"

  wk@wheatstone:~/b/gnupg/tmp$ echo $?
  2

Note that I have only specified a short key id because this is pretty
common and gpg prints only a warning. Okay.

The real problem is that there are several error messages - one is
sufficient to let gpg exit with a failure and git won't continue. There
are 2 different kinds of errors:

  gpg: Error: the key specification '0xE3FDFF218E45B72B' is ambiguous.

This is the keyid I specified on the command line. Let's check it:

$ ../g10/gpg2 -k 0xE3FDFF218E45B72B

[...]

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   ed25519/E3FDFF218E45B72B 2015-02-18 [expires: 2025-02-15]
  uid                 [ultimate] Werner Koch (wheatstone commit signing)

(and -k shows the same result).
What is the ambiguity here?

The other two error messages are identical one for --encrypt-to and one
for --default-key:

  gpg: Error: the key specification '1E42B367' is ambiguous.

Let's check it:

$ ../g10/gpg2 -k 1E42B367

[...]

gpg: Error: the key specification '1E42B367' is ambiguous.

gpg: (check argument of option '--encrypt-to')

gpg: error reading key block for '1E42B367': Unknown system error.

gpg: Warning: value '1E42B367' for --default-key should be a long keyid or a

fingerprint.

  gpg: Error: the key specification '1E42B367' is ambiguous.
  gpg: (check argument of option '--default-key')
  gpg: error reading key block for '1E42B367': Unknown system error.
  gpg: please do a --check-trustdb
  pub   dsa2048/F2AD85AC1E42B367 2007-12-31 [expires: 2018-12-31]
  uid                 [ unknown] Werner Koch <wk@gnupg.org>
  uid                 [ unknown] Werner Koch <wk@g10code.com>
  uid                 [ unknown] Werner Koch <werner@eifzilla.de>
  sub   dsa1024/4F0540D577F95F95 2011-11-02
  sub   rsa2048/1E0FE11D664D7444 2014-01-02 [expires: 2016-12-31]

Also not ambiguous.

So this new feature break existing installations. This is a complaint
as mentioned in T1128 (wk on Nov 06 2015, 10:57 AM / Roundup). Not due to performance but due to severe
breakage. This needs a lot more testing before we can release it.

Oops. I used a plain old keyring and not a keybox. However the effect is the same.