Hi Jeffrey and other GMime folks--
In notmuch, we now have reasonably well-integrated session-key stashing,
thanks to GMime. This has nice performance properties, as well as
potentially enabling "deletable private e-mail" in the future (via
subkey rotation and deletion).
However, i'm still seeing some performance trouble with a thread of ~40
encrypted + signed PGP/MIME messages. for example:
$ time notmuch show --decrypt=auto --format=json thread:00000000000d62a9 > /dev/null
real 0m15.456s
user 0m0.250s
sys 0m0.124s
$
I don't really understand why the wall-clock time is so large
proportional to the actual CPU time, but clearly the invocations of gpg
there are part of the problem.
Looking into how gmime uses gpgme, i notice that g_mime_gpgme_decrypt()
always does gpgme_op_decrypt_verify if the encryption blob is of type
OpenPGP. While decryption with verification is typically what the user
wants, i tried changing gmime to just invoke gpgme_op_decrypt() instead
of gpgme_op_decrypt_verify(), and wow:
$ time notmuch show --decrypt=auto --format=json thread:00000000000d52a9 > /dev/null
real 0m1.041s
user 0m0.207s
sys 0m0.117s
$
There is still a disparity between wall-clock and CPU time which i'll
look into further, but it's pretty clear that the additional
verification is a big part of it.
I'm looking into the idea of stashing signature verifications in
notmuch, so that notmuch can simply re-display an earlier signature
verification if that is warranted for the message. In that case,
notmuch wouldn't always need to verify signatures upon each decryption.
My experimental changes to GMime of course are non-trivial changes that
break functionality, so they aren't what GMime consumers (including
notmuch) want in every case.
Perhaps, though, the option to do this should instead be hidden behind a
new GMimeDecryptFlags variant, e.g. GMIME_DECRYPT_NO_VERIFY.
If there is interest in such a change, i could try to supply a mergeable
patch. let me know what you think.
--dkg
Attachment:
signature.asc
Description: PGP signature