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

Based on Werner's comment, I'm marking this bug as resolved.

I've removed it. Thanks.

(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.

Fixed in 84ebf15. Thanks!

Fixed in 84ebf15. Thanks!

This seems to work with 2.1.9. As such, I'm marking this issue as resolved.

$ gpg2 --list-options no-show-unusable-subkeys -k 4F43C989
pub rsa1024/4F43C989 2015-11-17
uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17

$ gpg2 --list-options show-unusable-subkeys -k 4F43C989
pub rsa1024/4F43C989 2015-11-17
uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17 [revoked: 2015-11-17]

It looks like this problem has been fixed in the meantime. As such, I'm marking
this bug as resolved. Thanks.

$ gpg2 --with-fingerprint 4F43C989.txt
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17
$ gpg2 --fingerprint 4F43C989
pub rsa1024/4F43C989 2015-11-17

Key fingerprint = A8D8 E9B9 D25D 6AB8 9997  AEE4 3817 872D 4F43 C989

uid [ unknown] Testing <testing@testing.com>
sub rsa1024/3CAD33EE 2015-11-17
sub rsa1024/FE39BBA1 2015-11-17
sub elg1024/A10351BD 2015-11-17

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>

For what it is worth, this does not appear to be an issue for GnuPG 2.1.x. If
the specified home directory does not exist, GnuPG quickly fails:

$ gpg2 --homedir /tmp/gpg-temp --gen-key
gpg (GnuPG) 2.1.10-beta132; Copyright (C) 2015 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

gpg: NOTE: THIS IS A DEVELOPMENT VERSION!
gpg: It is only intended for test purposes and should NOT be
gpg: used in a production environment or with production keys!
gpg: keyblock resource '/tmp/gpg-temp/pubring.kbx': No such file or directory
Note: Use "gpg2 --full-gen-key" for a full featured key generation dialog.

GnuPG needs to construct a user ID to identify your key.

Real name: Foo
Name must be at least 5 characters long
Real name: Foobar
Email address:
You selected this USER-ID:

    "Foobar"

Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
gpg: failed to create temporary file
'/tmp/gpg-temp/.#lk0x00000000017158f0.grit.10925': No such file or directory
gpg: can't connect to the agent: No such file or directory
gpg: agent_genkey failed: No agent running
Key generation failed: No agent running

I just tried following the steps using gpg2 (2.1.9) and I can't reproduce the
problem. It would be good if we had an exact sequence of commands that
reproduced the problem.

Fixed in ad9befa.

Note: to reproduce:

gpg2 --no-options --no-default-keyring --keyring pubring.gpg -k

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

This link has been removed long ago. Nevertheless thanks for the bug report.

It seems the issue was fixed in the last 2.5 years.

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.

This is a really old patch. Since it was reported, dirmngr has been
significantly reworked and integrated into GnuPG. Further, GnuPG's configure.ac
checks for ber_free. Since this is (I'm assuming) in the same SO as ber_alloc
(which this patch checks for) this patch is already effectively applied. Given
this, I'm closing this issue.

This sounds like a user configuration problem. Given Werner's reply, the lack
of response from the reporter and the amount of time that has gone by, I'm
closing this.

According to Werner, this is probably not a bug. Closing since the user never
followed up.

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

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

I'm marking this as resolved. If it is still an issue, please feel free to
reopen. Thanks.

Duplicate of T1143

Note: T1232 is related.

This is ambiguous and the email is not mentioned. Given how old this is and
Niibe's opinion, I'm closing this issue.

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

Given how hold this is, it would be nice if someone could confirm this is till
an issue.

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

Fix in f99830b.

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).

The Debian package still carries this patch. Since Niibe is (Debian)
downstream, it would be good if he could take another look at this.

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.

I've added this now.

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

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.

Since this is not a GnuPG problem, I'm closing this bug.

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

Comitted in a958ffd.