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.
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users