dirmngr, ldap, dirmngr_ldap, and the ldap "wrapper"

Neal H. Walfield neal at walfield.org
Fri Jan 6 14:35:59 CET 2017

This appears to not have been addressed.  As such, I opened the
following issue so we don't forget about it:


On Thu, 10 Nov 2016 12:06:53 +0100,
Daniel Kahn Gillmor wrote:
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain (7bit)>]
> Hi all--
> dirmngr in debian used to have a weaker dependency (a "Recommends:"
> instead of "Depends:") on the libldap binary package, so users who
> wanted a smaller system and didn't need dirmngr ldap access could
> install dirmngr without installing libldap.  Of course, dirmngr_ldap
> would fail on those systems.  Currently, however, libldap is a hard
> dependency of dirmngr, because dirmngr links in ks-engine-ldap.c
> Comments in the header of dirmngr/ldap-wrapper.c say:
> ----------
>    We can't use LDAP directly for these reasons:
>    1. On some systems the LDAP library uses (indirectly) pthreads and
>       that is not compatible with PTh.
>    2. It is huge library in particular if TLS comes into play.  So
>       problems with unfreed memory might turn up and we don't want
>       this in a long running daemon.
>    3. There is no easy way for timeouts. In particular the timeout
>       value does not work for DNS lookups (well, this is usual) and it
>       seems not to work while loading a large attribute like a
>       CRL. Having a separate process allows us to either tell the
>       process to commit suicide or have our own housekepping function
>       kill it after some time.  The latter also allows proper
>       cancellation of a query at any point of time.
>    4. Given that we are going out to the network and usually get back
>       a long response, the fork/exec overhead is acceptable.
> ----------
> The inclusion of ks-engine-ldap.c appears to have happened in
> 51341badb623927f2a358588c725a356fc77dbe7.  Has the rationale in
> ldap-wrapper.c been reconsidered or made obsolete for some reason?  If
> so, it should be updated.  If not, should we try to re-separate
> dirmngr's use of ldap back into the wrapper?
> Any thoughts?
>           --dkg
> [1.2 signature.asc <application/pgp-signature (7bit)>]
> Signature made by expired key 24ECFF5AFF68370A Daniel Kahn Gillmor <dkg at fifthhorseman.net>
> [2  <text/plain; us-ascii (7bit)>]
> _______________________________________________
> Gnupg-devel mailing list
> Gnupg-devel at gnupg.org
> http://lists.gnupg.org/mailman/listinfo/gnupg-devel

More information about the Gnupg-devel mailing list