cd2d685 fixes the assert. I don't see the utility of checking keyid (gpg will
do that). Closing.

Based on Werner's comment, I'm changing this to nobug and marking the issue as
resolved.

(At least) 2.1.9 should support version 3 (see dirmngr/ks-engine-ldap.c:492).
If this is still not working, please reopen this bug. Thanks.

I've fixed this with commit 0b86c74 by making it possible to select keys using
the key id. Consider:

gpg> key 4BFA08E4

pub rsa4096/D21739E9

created: 2007-06-02  expires: 2016-01-21  usage: SC  
validity: unknown

sub rsa4096/21484CFF

created: 2007-06-02  expired: 2015-02-26  usage: E

sub* rsa2048/4BFA08E4

created: 2008-06-19  expires: 2016-01-21  usage: A

sub rsa4096/1BFDFA5C

created: 2013-03-12  expires: 2016-01-21  usage: S

sub rsa2432/0CA757FB

created: 2013-09-11  expires: 2016-09-14  usage:

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub rsa4096/14D5DA70

created: 2015-01-21  expires: 2016-01-21  usage: E

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

sub ed25519/BD7CFAB5

created: 2014-11-07  expired: 2015-05-06  usage: A

[ unknown] (1). Daniel Kahn Gillmor <dkg@fifthhorseman.net>
[ unknown] (2) Daniel Kahn Gillmor <dkg@openflows.com>
[ revoked] (3) Daniel Kahn Gillmor <dkg@astro.columbia.edu>
[ revoked] (4) Daniel Kahn Gillmor <dkg-debian.org@fifthhorseman.net>
[ unknown] (5) [jpeg image of size 3515]
[ unknown] (6) Daniel Kahn Gillmor <dkg@debian.org>
[ unknown] (7) Daniel Kahn Gillmor <dkg@aclu.org>

Bernhard - this is an issue of security, it is not a place for you to
exercise corruption by using your influence over administrators to shut down
opinions you disagree with.

You have made a statement that I am absolutely confident that no security
professional will support: "We will keep the non-TLS access, because there
are some people that will lose access otherwise.". Aside form this
statement being almost certainly totally untrue, this is nevertheless NOT a
valid reason to continue to distribute a security product over known
compromiseable channels. If anyone cannot get GPG because of TLS (which I
doubt), that is NOT a reason to for everyone to get GPG over an insecure
channel. Like I've said before, security-downgrade attacks are the most
effective weapon used by adversaries. Do not make is so easy for them.

Let me suggest a resolution to this problem, since we seem to be at a
stalemate:

Let us pick a security professional who is known and trusted. You can write
down your case for why you do not want to use TLS, and I will write down my
case why I want TLS to be mandatory, and we will each give our cases to this
professional.

If they pick your case, I will let you close this ticket and I will not come
back.

If they pick my case, you will resign from the GnuPG project and not come
back.

Deal?

Chris,

the admins tell me that it is easiest to remove your user account
to withdraw updating rights to this issue. This I may be forced to do,
unless we find a better solution for civility and availability of this tracker.

Regards,
Bernhard

This is still open: http://files.gpg4win.org/gpg4win-2.2.6.exe
So this stays open: T1858

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

This would add a lot of complexity because some users will soon request
configurable colors and attributes as well as different output formatting.

I suggest to write a wrapper to do this or resort to one of the GUI tools.

Mate - it's this simple. For as long as you're distributing a security
product over plaintext insecure channels, this bug needs to stay open.

TLS will NOT prevent anyone downloading this, no matter how hard you cling
to that irrational idea. If you work for someone who is exploiting this
attack vector SHAME ON YOU!!!

Stop wasting everyones time. If you don't want to fix this, go away and do
something else, stop preventing someone who *can* fix it from actually doing
that by messing with this ticket.

That should go into the keylisting. Here is a listing of a revoked
key:

  pub   dsa1024/269E78D84738350A 1999-08-16 [revoked: 2011-02-15]
        Key fingerprint = 72A2 A242 8623 84A9 5910  C454 269E 78D8 4738 350A
        Keygrip = 2BBB5EF3D036022DD66EF4386680C194352A2EC2
  uid                 [ revoked] Florian Lohoff <flo@[...]>
  uid                 [ revoked] Florian Lohoff <flo@[...]>
  uid                 [ revoked] Florian Lohoff <flor[...]>

Another line after the Keygrip line could show key revocation
information. To show user id revocations a list option is anyway
required:

  $ gpg --list-options show-unusable-uids  \
     --with-fingerprint  --with-keygrip -k 6C7EE1B8621CC013
  pub   dsa1024/6C7EE1B8621CC013 1998-07-07 [expired: 2004-12-31]
        Key fingerprint = ECAF 7590 EB34 43B5 C7CF  3ACB 6C7E E1B8 621C C013
        Keygrip = E3003A38C3CCB63DFB39998A6C8A78EB9498E42A
  uid                 [ expired] Werner Koch <wk@gnupg.org>
  uid                 [ expired] Werner Koch <werner.koch@guug.de>
  uid                 [ expired] Werner Koch <wk@[...].com>
  uid                 [ revoked] Werner Koch <wk@openit.de>

A similar formatted revocation reason could be shown after the revoked
user id. It would be best to indent that to align with the [revoked]
string.

And of course we also need to come up with a --with-colon format for
both cases.

Iff we do this it should only go into 2.1 thus I changed the Version field.

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.

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

(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

In 2.1, these options are supported. They are not support in 1.4, but they are
in 1.4's manual.

At most, this is a performance bug. However, applygnupgdefaults isn't
performance critical. There is no reason to apply this so I'm dropping it.

https://www.gnupg.org/documentation/manpage.en.html is way out of date. Is
there a way to automatically generate this page (it needs to be converted to the
.org format).

This seems to still be a problem:

$ gpg2 --keyserver hkp://keyring.debian.org --search-keys dkg
gpg: error searching keyserver: No data
gpg: keyserver search failed: No data

This bug report is very old and 2.0.17 is no longer supported. The right way
forward is to rerun the test suite with the latest version on a modern OS.
However, I expect that if these failures were still a problem, we'd have heard
about them. As such, I'm closing this bug.

Added the option --only-sign-text-ids in 28e1982

According to Werner's comment, this is not a bug so closing.

Note: T1232 is related.

The warning is in the documentation. I'm closing this.

The main complaint was fixed in 2b27acc and the program was marked as deprecated
in the documentation.

Where should this output be displayed? When doing gpg2 -K, revoked user ids are
not shown. Perhaps in --edit-key? Nevertheless, it would be nice to have a
command line option to get this information directly.

Checked in (e8c53fc).

Werner: This patch is still relevant and it only changes diagnostics so it
shouldn't impact any existing code. Okay to apply?

I can't find any current information about PocketConsole or PocketGnuPG on the
web. I'm assuming that the software is not supported anymore and, as such, I've
removed the link.

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

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

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

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.

Whoops, I closed the wrong bug report, sorry. Reopening.

Comitted in a958ffd.

Comitted in a958ffd.

The patches are now rebased on top of f7505b550dd591e33d3a3fab9277c43c460f1bad.

In addition to these a modified rsa generator is needed to be FIPS 186-4 compliant.

We ended up using this patch from Fedora:
http://pkgs.fedoraproject.org/cgit/libgcrypt.git/tree/libgcrypt-1.6.3-rsa-fips-keygen.patch

Committed (ec409e6).

D253: 718_0011-Fix-testsuite-after-the-FIPS-adjustments.patch

D254: 717_0010-Add-new-pss-option-to-fipsdrv.patch

D255: 716_0009-Add-possibility-to-specify-salt-length-for-PSS-verif.patch

D256: 715_0008-fipsdrv-Add-support-for-RSA-keygen-tests.patch

D257: 714_0007-Fixes-for-RSA-testsuite-in-FIPS-mode.patch

D258: 713_0005-Use-2048-bit-RSA-keys-for-selftest.patch

D259: 712_0004-Disable-non-allowed-algorithms-in-FIPS-mode.patch

D260: 711_0003-PBKDF2-add-upper-bound-for-derived-key-length.patch

D261: 710_0002-ECDSA-adjustments-for-FIPS-186-4.patch

D262: 709_0001-DSA-adjustments-to-conform-with-FIPS-186-4.patch

Fix in cd2d685.

Verifying the unwrapped data also works:

$ gpg2 --decrypt --unwrap /tmp/a > /tmp/b
Please enter the passphrase to unlock the OpenPGP secret key:
"Testing (insecure!)"
1024-bit RSA key, ID 6EA74366,
created 2015-09-18 (main key ID EE37CF96).

Passphrase:
gpg: encrypted with 1024-bit RSA key, ID 6EA74366, created 2015-09-18

"Testing (insecure!)"

$ gpg2 --verify /tmp/b
gpg: Signature made Wed 04 Nov 2015 01:53:31 PM CET using RSA key ID EE37CF96
gpg: Good signature from "Testing (insecure!)" [full]
gpg: Verified 7 messages signed by "Testing (insecure!)" (key: 362D 3527 F53A
AD19 71AA FDE6 5885 9975 EE37 CF96, policy: good) in the past 1 day, 20 hours.
The most recent message was verified 22 hours, 40 minutes ago.

D89: 708_0002-gpg-Add-support-for-unwrapping-the-outer-level-of-en.patch