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?
> [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
More information about the Gnupg-devel