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:

  https://bugs.gnupg.org/gnupg/issue2908

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