Long delay when opening signed emails

[Daniel Kahn Gillmor]

Hi Michal--

On Tue 2018-01-30 17:17:54 +0100, Michal Sojka wrote:
> Hi all,
>
> I experience annoyingly long delay, when opening some signed emails in
> Emacs. This is likely related to the following lines appearing in my
> log when opening the email:
>
> Jan 30 17:07:46 dirmngr[7526]: no CRL available for issuer id A401B7A860C859FEA90E1A7EEE2BAF37C7FB918F
> Jan 30 17:08:06 dirmngr[7526]: resolving 'crl3.digicert.com' failed: Server indicated a failure
> Jan 30 17:08:06 dirmngr[7526]: can't connect to 'crl3.digicert.com': host not found
> Jan 30 17:08:06 dirmngr[7526]: error retrieving 'http://crl3.digicert.com/TERENAeSciencePersonalCA3.crl': Server indicated a failure
> Jan 30 17:08:06 dirmngr[7526]: crl_fetch via DP failed: Server indicated a failure
> Jan 30 17:08:06 dirmngr[7526]: command 'ISVALID' failed: Server indicated a failure
>
> I don't understand why resolving crl3.digicert.com fails, because it
> works from command line.

I think the e-mail in question is S/MIME-signed.  is that right?

It looks like dirmngr is having some problems with network connectivity
-- perhaps it has the wrong information about DNS resolvers?

as a workaround, have you tried terminating dirmngr to let it restart
when needed?  you can do that with:

    gpgconf --kill dirmngr

(it should respawn automatically as needed)

> Any suggestions how to solve the failure or at least to get rid of the
> delay?

Apart from the workaround described above, if you decide that you'd
rather avoid doing CRL checks in general (you might want that to avoid
metadata leakage at least), you could put "disable-crl-checks" on its
own line in ~/.gnupg/gpgsm.conf

See also https://dev.gnupg.org/T3348 -- i'm asking upstream to default
to False there.

hth,

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <http://notmuchmail.org/pipermail/notmuch/attachments/20180130/965044a9/attachment.sig>