Infinite loop?

[Phil Pennock]

On 2019-06-25 at 18:47 -0400, Daniel Kahn Gillmor via Gnupg-users wrote:
> Interesting!  my pubring.kbx is 147MiB, but GnuPG still should not run
> forever when doing --list-keys.  It takes 17s to complete the listing of
> my pubring.kbx, as measured by "time gpg --list-keys > /dev/null"

With GnuPG 2.2.16 :

% ls -ldh ~/.gnupg/pubring.kbx
-rw-r--r-- 1 pdp pdp 241M Jun 22 22:16 /home/pdp/.gnupg/pubring.kbx
% time gpg --list-keys >/dev/null 
[...]
gpg --list-keys > /dev/null  1473.99s user 1965.72s system 99% cpu 57:19.85 total
% kbxutil --stats .gnupg/pubring.kbx
Total number of blobs:     5640
               header:        1
                empty:        0
              openpgp:     5638
                 x509:        1
          non flagged:     5638
       secret flagged:        0
    ephemeral flagged:        1

This is an "Intel(R) Atom(TM) CPU D2500   @ 1.86GHz" and is where I've
long had my high-security keys.  One bright side to this box and its
speed: it's immune to speculative prediction attacks.  None of that
newfangled nonsense.  ;)

I've long been resigned to this being normal.  An unthinking import of a
fuller keyring (probably this one) to my recent new work laptop
(Thinkpad X1 Carbon, running Ubuntu) led to confusion as I re-acclimated
to a Linux desktop after years of macOS usage, because core parts of
system preferences appeared to just hang and do nothing.  Until I
finally realized the problem and nuked the keyring down to a dozen keys
which most mattered here.  I hadn't realize that my GnuPG keyring was
being exposed in my view of the preferences.

In fact, I got so used to seahorse just dying that I adjusted my login
scripts to ignore it and fire up my own ssh-agent so that I wouldn't
lose the ability to log into other machines.  I made that conditional
upon the socket being dead and grumpily chalked it up to Linux
flakiness, but I see now that this hasn't been getting triggered
recently.

The X1 Carbon is 8 claimed cores of "Intel(R) Core(TM) i7-8650U CPU @
1.90GHz" and 16GiB RAM.  It was definitely not happy at a keyring which
lets me comfortably verify software releases from signers in the strong
set.

> If you still have a copy of the corrupt 20M pubring.gpg, it might be
> interesting to see it as an example, because it sounds like it's
> tickling a bug.

If you're interested, I can share mine; there are no "secret" keys in it
and I'll trust you not to leak the communications graph of which
software I care about verifying :) or the public signatures from the
strong set showing where I've been over the years or the local
signatures for "yeah, I grabbed these fingerprints from a web-page, I'll
trust them locally but won't attest to them publicly".

-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 996 bytes
Desc: Digital signature
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190625/f59a6159/attachment.sig>