--list-secret-keys abysmally slow
Sascha Silbe
sascha-ml-reply-to-2011-1 at silbe.org
Mon Jan 10 19:09:49 CET 2011
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>
More information about the Gnupg-devel
mailing list