I'm seeing this behavior as well. For a test keyring with 13 keys, 49 User
IDs, and 7227 signatures, stored on a tmpfs on linux kernel 3.16, gpg2
--list-sigs with a pubring.kbx takes over 3 seconds (mostly kernelspace), but
with an old-style pubring.gpg takes 0.6 seconds (mostly userspace)

Maybe it makes more sense to mmap the keybox rather than trying to seek and read
inside it?

I'm also seeing this extreme delay from gpg --list-sigs 2.1.2 on a large
keyring, particularly when using kbx. It seems likely that there is a bug here.

This shows up elsewhere too:

http://forum.yubico.com/viewtopic.php?f=26&t=1171

says:

For some inexplicable reason, GnuPG cannot extract the public key from a
smartcard except during generation. That means that to use the key from
another computer, you either have to copy the public key from the original
computer's GnuPG keyring, or you need to set the URL attribute to a file
which contains the PGP public key block. Otherwise, the token is effectively
locked to a single computer, and unuseable if you happen to trash your
keyring unless you regenerate a key.

It would be nice to streamline this case.

D284: 554_avoid-crash-with-zero-length-DIR.txt

Jason Donenfeld has a patch for this:

http://thread.gmane.org/gmane.comp.encryption.gpg.devel/19654

i've tested this with gnupg 2.1.1, and gnupg 2.1.1 does provide a non-zero
return code if the passphrase fails.

oh, and this appears to be the case for 1.4.x, 2.0.x, and 2.1.x

That link to the debian bts is a little wacky, somehow roundup is attaching the
comma to the end of it. it should be: https://bugs.debian.org/771976

Any word on this? It would be nice to see something like this merged.

Can i get an update on where this patch stands? I'm concerned that people are
actively sniffing around the idea of crafting duplicate short keyids:

D149: 332_1340.diff

Attached is a proposed patch that should permit passing long keyIDs or full
fingerprints to the keyservers.

Given that the referenced draft was written in 2003, we now have 8 years of
documented expectations that keyservers can do this. The dominant keyserver
implementation today (SKS) can handle this with no trouble.

this is not a limitation of the keyservers; gpg itself is stripping all but the
short keyid. adding "--keyserver-options debug" to the command shows that in
every case, gpg is requesting the following URL:

I appreciate that PKCS#12 is stupid and baroque, but if the goal is
interoperability with other software, it seems like other GNU tools would be a
reasonable target at least :)

A colleague just observed that expiration dates are also missing when
--list-secret-keys is used without a matching string.

D87: 223_default-preference-list-change.diff

Here is an example OpenPGP certificate with only the certify flag set, if you
want to test with it.

D65: 179_DETAILS-update

I'm happy to assign copyright for this patch to the FSF, if that's needed.

Interestingly, batch mode appears to detect the overflow. In that case,
overflows are silently rewritten to the creation timestamp plus one second:

Actually, the capabilities *are* listed with the secret keys, as long as you
provide a string to match against. The only case where they aren't listed is
when there's no matching string.

This seems to happen whether or not i'm logged in.

I've tested this with gnupg and gnupg2, and both seem to behave this way.

Whoops! Of course, the second line of the demonstration should actually read:

Any word on this? The patch should be short enough for a quick review. It
problem can be demonstrated by setting GPGID to the key id of an RSA key, and doing:

D53: 161_show-photo-validity.patch

gpgkey2ssh very poorly documented (no manpage, no help output), but it is
shipped with the source tarball, so i figure it should work properly at least
when the correct parameters are offered.

D52: 160_473841.patch