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

Daniel Kahn Gillmor dkg at fifthhorseman.net
Thu Nov 10 12:06:53 CET 2016


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161110/363bfd34/attachment.sig>


More information about the Gnupg-devel mailing list