Hi Jack: Am 02.08.17 18:08 schrieb(en) Jack:
Yes, it turns out I do have auto-key-retrieve enabled, and per your suggestion will disable it. However, I assume I would get the same delay when manually retrieving (or trying to retrieve) the key manually.
Yes. But as Balsa runs this in a separate thread (recent git version) or forks gpg (older versions), this does not block the interface.
My underlying question is whether the need to add "standard-resolver" to dirmngr.com indicates a bug anywhere or just a configuration issue that perhaps just should have been of higher visibility.
Good question… Actually, I /thought/ it was needed for S/MIME only. However, the latest GnuPG manual says [1] <snip> Since version 2.1 of GnuPG, dirmngr takes care of accessing the OpenPGP keyservers. As with previous versions it is also used as a server for managing and downloading certificate revocation lists (CRLs) for X.509 certificates, downloading X.509 certificates, and providing access to OCSP providers. Dirmngr is invoked internally by gpg, gpgsm, or via the gpg-connect-agent tool. </snip> The docs simply say about the "standard-resolver" option: <snip> standard-resolver This option forces the use of the system’s standard DNS resolver code. This is mainly used for debugging. </snip> I guess the best place for your question would be one of the GnuPG lists [2], probably either gnupg-users or gnupg-devel. Cheers, Albrecht. [1] <https://www.gnupg.org/documentation/manuals/gnupg/Invoking-DIRMNGR.html> [2] <https://www.gnupg.org/documentation/mailing-lists.html>
pgpsWkqAqPEdT.pgp
Description: PGP signature
_______________________________________________ balsa-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/balsa-list
