This hasn't gotten a response on the ML, so opening this issue so it doesn't get
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?