Infinite loop?

[Daniel Kahn Gillmor]

On Tue 2019-06-25 23:03:18 -0400, Phil Pennock wrote:
> 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'm glad you have a sense of humor about it, but this sounds
unacceptably slow to me.  --list-keys isn't even doing any cryptographic
processing, right?  

> I've long been resigned to this being normal.

the timing you show above suggests that --list-keys operates at ~100
keys per minute, or not even 2 keys per second.

And why on earth is so much time spent in the kernel?  for my own run,
the breakdown is:

real	0m17.555s
user	0m17.367s
sys	0m0.184s

But yours appears to have > 50% of its time spent in "sys".  Can you use
strace -T or some other profiler to see what system calls it's making
that makes it spend so much time in the kernel?

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

numbers like 5K keys and 241MiB are not large for a machine of this
caliber.  my own kbxutil --stats looks like:

Total number of blobs:     4166
               header:        1
                empty:        0
              openpgp:     3787
                 x509:      378
          non flagged:     4165
       secret flagged:        0
    ephemeral flagged:        0

If you import your larger keyring on the X1 Carbon, what is the output
of "time gpg --list-keys > /dev/null" there?

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

If the issue is just a large keyring, i can generate that myself pretty
easily, thanks.  I was concerned by the OP that there was an acual
infinite loop somewhere.  But if the run is just taking a long time
because of unoptimized code, we should try to address that as a separate
issue.

        --dkg

ps fwiw, i think even 17s is too long for my own 4K keys, esp. with a
   hot fileysystem cache.  that's still only ~220 per second, but it's
   managable, and i've had enough other things i want to get fixed in
   GnuPG that i haven't dug in too deeply to see where the problem is or
   how it could be sped up.  But it's nothing near the order of
   magnitude that you're describing.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20190626/09387c80/attachment-0001.sig>