- Event Series
- This event is an instance of E855: Weekly Standup, and repeats every week.
Event Timeline
I checked out LDAP code in dirmngr. Actually we have two versions:
The original one which uses the dirmngr_ldap helper to a) avoid
problems with linking to another version of libgcrypt via
openldap and b) to allow for a reliable timeout which also
handles a stuck LDAP connection (e.g. during connect of while in
get_values). This code is used to fetch CRLs and X.509 certs.
The newer code which is the old 2.0 key server helper ported to
dirmngr. However, it introduced the very same problem we fixed
we avoided with dirmngr_ldap. Further the semantics are
different. This code, which is used for OpenPGP, also allow to
write to the LDAP server.
A simple migration to dirmngr_ldap is not straightforward because
it is important for dirmngr to first know which version of the
LDAP schema is in use. Thus dirmngr_ldap would need carry some
state.
Other problems which we see in both code parts:
There is no clear indication what "ldaps" means. It might be
STARTTLS or LDAP-over-TLS. I would propose to straighten this up
so that ldaps uses STARTTLS. An extra flag can be used to switch
to LDAP-over-TLS; this might be as simple as looking at the port,
but I am not sure. Note that Windows recently dropped support
for LDAP-over-TLS.
Another thing is that LDAP URIs are hard to understand due to the
extra percent quoting required. The way we specify the CRL/X.509
servers is easier to understand. I would propose to use a mix here:
If we see "foo://" this indicates an URI as currently used by the
OpenPGP part. But if we see "foo:number" or "foo::" this
indicates the ldapserver file method which uses:
hostname:port:username:password:base_dn:flags
The flags can then be used to request STARTTLS or LDAP-over-TLS.
Right now we allow here "ldap" and "ldaps"; these flags can be kept
for backward compatibility.
If we want to drop the dirmngr_ldap helper we could do so on Unix
only if we build our own version of openldap to make sure the
same libgcrypt is used. On Windows all this is not required.
However, we would need to rely on proper timeout handling in
OpenLDAP which is not guaranteed. I have not tested whether
timeouts are more reliable on Windows (but I guess they are)
Another option is to change the dirmngr_ldap helper into an
Assuan server so that it can be stateful. We could then run such
helper for each server/port/user/ combination as needed and
terminate them only on error. This has the additional benefit
that we easily avoid the open connection overhead.
Such a large change can only be done for 2.3, however straighten
STARTTLS and URLs should also be done for 2.2 even if we will
still have the double version linked thing and no proper timeout
for OpenPGP.