--list-secret-keys abysmally slow

[Sascha Silbe]

Hi!

(Originally report as issue #1312 [1], but I was told to post here instead).

--list-secret-keys takes a lot of time in the latest development version:

sascha.silbe at twin:~$ time gpg2 --list-secret-keys
gpg: please do a --check-trustdb
/home/sascha.silbe/.gnupg/pubring.gpg
-------------------------------------
sec#  4096R/A13AC1B1 2008-06-03 [expires: 2013-06-02]
uid                  Sascha Silbe <sascha-pgp at silbe.org>
uid                  Sascha Silbe <silbe at activitycentral.com>
ssb#  2048R/2E966FF1 2008-06-03 [expires: 2013-06-02]
ssb#  2048R/4C1770DA 2008-06-03 [expires: 2013-06-02]
ssb   2048R/7775EB20 2010-03-07


real    0m11.769s
user    0m10.273s
sys     0m0.544s
sascha.silbe at twin:~$ 

This is on my fastest system, containing an Athlon X2 BE-2300. As it's entirely CPU bound I expect it to be much worse on my other systems.


2.0.14 OTOH is reasonably fast and lists a lot more keys (one of which isn't expired):

sascha.silbe at twin:~$ time /usr/bin/gpg2 --list-secret-keys
gpg: please do a --check-trustdb
/home/sascha.silbe/.gnupg/secring.gpg
-------------------------------------
sec   1024D/6135C35B 2000-06-15
uid                  Sascha Silbe <Sascha.Silbe at ldknet.org>
uid                  Old key - please use 74E5CF87 instead
ssb   2048g/876FE678 2000-06-15

sec    768R/E24E152D 1997-07-31
uid                  Sascha M. Silbe <Sascha_Silbe at pb.donut.de> - 768-Key
uid                  Sascha M. Silbe <postmaster at pb.donut.de> - 768-Key

sec   2048R/200B8F6D 1997-07-31
uid                  Sascha M. Silbe <Sascha_Silbe at pb.donut.de> - 2048-Key
uid                  Sascha M. Silbe <postmaster at pb.donut.de> - 2048-Key

sec   1024R/3BDC71ED 1997-07-31
uid                  Sascha M. Silbe <Sascha_Silbe at pb.donut.de> - 1024-Key
uid                  Sascha M. Silbe <postmaster at pb.donut.de> - 1024-Key

sec   1024R/7337BD6D 1999-06-12
uid                  Sascha Silbe <Sascha.Silbe at ldknet.org>
uid                  Old key - please use 74E5CF87 instead

sec   1024D/74E5CF87 2002-06-07 [expires: 2005-11-10]
uid                  Sascha Silbe <sascha at silbe.org>
uid                  Sascha Silbe <silbe at fsi.uni-tuebingen.de>
uid                  Sascha Silbe <silbe at informatik.uni-tuebingen.de>
uid                  Sascha Silbe <sascha.silbe at student.uni-tuebingen.de>
ssb   2048g/4623B45A 2002-06-07

sec   1024D/F9FB6446 2005-08-20 [expires: 2010-08-19]
uid                  Sascha Silbe <sascha-pgp at silbe.org>
ssb   2048g/56B5E5DA 2005-08-20
ssb   1024D/A57475A3 2007-02-09

sec   4096R/A13AC1B1 2008-06-03 [expires: 2013-06-02]
uid                  Sascha Silbe <sascha-pgp at silbe.org>
uid                  Sascha Silbe <silbe at activitycentral.com>
ssb   2048R/2E966FF1 2008-06-03
ssb   2048R/4C1770DA 2008-06-03
ssb   2048R/7775EB20 2010-03-07

sec   4096R/666005F4 2008-12-29 [expires: 2016-12-27]
[uid omitted for privacy reasons]


real    0m0.109s
user    0m0.016s
sys     0m0.044s
sascha.silbe at twin:~$ 

strace'ing gpg2 and gpg-agent suggests that all public keys are probed. With currently about 7k public keys in the ring (prior to an HD crash it was even more) it's clear why --list-secret-keys is that slow.

This is probably a known / expected issue (the gpg-agent protocol doesn't seem to have a command for listing secret keys), but I didn't find it documented anywhere.

PS: The difference in the number of secret keys was related to the fact
    that I had not "imported" the ~/.gnupg/secring.gpg yet. The secret
    key stubs for my main key might have come from using gpg-agent in
    ssh-agent "emulation" mode before (with 2.0.14).
    The performance did not change after the import.

Sascha

[1] https://bugs.g10code.com/gnupg/issue1312
-- 
http://sascha.silbe.org/
http://www.infra-silbe.de/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: </pipermail/attachments/20110110/b7c37bbd/attachment.pgp>