Control: forwarded 775933

Hi Andrew--

On Wed 2015-01-21 12:25:13 -0500, Andrew Gallagher wrote:

> Enigmail appears to call 'gpg --list-keys' when trying to work out if it
> should encrypt an email, even if that mail has only one recipient. This means 
> slurping up every single key ID into memory, required or not. It also causes 
> gpg to walk its entire database, which is ridiculously inefficient - with a 
> large keyring and gpg2 this can take several minutes, during which time gpg 
> hogs 99% of CPU. (gpg1 is faster, but there is still a noticeable delay)

Yep, i've seen this problem myself, and have initially tried to get it
fixed upstream in gpg by getting gpg to speed up the --list-keys
output.  We've had some reasonable speedup already there.

But i agree with you that enigmail should also avoid doing this
operation where possible.  I've just forwarded the bug upstream to

> Is this all really necessary? It would be hundreds of times faster to call 
> 'gpg --list-keys $email' for each recipient in turn. 

This is likely true if you have a large keyring and a few recipients,
but might not be the case if you have a small keyring and many
recipients :/

However, this is something amenable to profiling, and the speedup in the
large-keyring case is substantial (i've measured it locally and reported
those measurements at the upstream bug).

BTW, which version of gpg2 are you using?  I found that gpg2 2.1.2 (from
debian experimental) is actually significantly faster than gpg 1.4.18.


Attachment: signature.asc
Description: PGP signature

Pkg-mozext-maintainers mailing list

Reply via email to