Re: [gmime-devel] OpenPGP decryption without verification

[Jeffrey Stedfast <jestedfa microsoft com>]

Hi Daniel,

(Sorry for the top-post but Outlook makes inline replies impossible because of the way it quotes, ugh)

I think GMIME_DECRYPT_NO_VERIFY is a fantastic idea for solving your problem while at the same time making 
the least invasive changes.

Since it was such a simple change, I've already committed a patch for this feature.

Great work digging into this performance issue!

Jeff

On 10/1/19, 12:06 AM, "gmime-devel-list on behalf of Daniel Kahn Gillmor via gmime-devel-list" 
<gmime-devel-list-bounces gnome org on behalf of gmime-devel-list gnome org> wrote:

    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