performance of gpg --list-secret-keys with large keyrings

[Daniel Kahn Gillmor]

I'm noticing a serious degradation in performance on large public
keyrings from gpg 1.4.x to 2.1.x for the command:

 gpg --list-secret-keys

This is in a demo account that has 13 secret keys and over 2600 public
keys in the keyring.  The public keys are in pubring.gpg and not
pubring.kbx (no conversion has happened yet).  Here's the timings:

0 demo at saturn:~$ time gpg --with-colons --list-secret-keys  | grep -c '^sec:'
13

real	0m0.014s
user	0m0.008s
sys	0m0.004s
0 demo at saturn:~$ time gpg2 --with-colons --list-secret-keys  | grep -c '^sec:'
13

real	0m7.886s
user	0m7.544s
sys	0m0.172s
0 demo at saturn:~$ time gpg --with-colons --list-keys  | grep -c '^pub:'
2637

real	0m8.958s
user	0m8.812s
sys	0m0.160s
0 demo at saturn:~$ time gpg2 --with-colons --list-keys  | grep -c '^pub:'
2637

real	0m8.602s
user	0m8.420s
sys	0m0.188s
0 demo at saturn:~$ 


I think the move from 0.014s to >7s for --list-secret-keys is because
gpg 2.1 implements --list-secret-keys by asking the agent about every
known public key to see if it has the secret material for it.

Surely it would be more efficient if the agent could just list the keys
directly.  But maybe there are security reasons that we don't want to
expose such a list through the agent's interface?  If so, what are the
reasons?

Regards,

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 948 bytes
Desc: not available
URL: </pipermail/attachments/20141010/dccdbfbe/attachment-0001.sig>