Rich Megginson wrote:
I apologize for cross posting, but I think this problem involves both
Thunderbird and LDAP developers.
There is a problem with Thunderbird and pam_ldap/nss_ldap. The problem
exists because Thunderbird uses the Mozilla LDAP C SDK and
pam_ldap/nss_ldap (on most linux/*bsd systems anyway) use the OpenLDAP C
SDK. The two APIs, while similar, have some incompatibilities, which
cause crashing when either Thunderbird calls an OpenLDAP function or
pam_ldap/nss_ldap call a Mozilla LDAP function. There has been a bug
open about this problem for a while, and this bug lists some of the
proposed solutions to this problem -
https://bugzilla.mozilla.org/show_bug.cgi?id=292127
I'd like to use this thread to discuss some possible solutions. One
solution that has been proposed several times is to just use the
OpenLDAP API for Thunderbird. This has a couple of problems:
1) May require some porting work in cases where Thunderbird depends on
some API functionality present in the Mozilla API but not in OpenLDAP.
2) Cannot use LDAP with TLS/SSL because Thunderbird uses NSS while
OpenLDAP uses OpenSSL.
I do not have a lot of familiarity with the current OpenLDAP client
libraries, but I don't think it makes a lot of sense to have TBird use
OpenLDAP's libraries unless we are "end of life"-ing the
mozilla/directory/c-sdk code.
Another solution is to use build time and/or run time linker options so
that Thunderbird only uses Mozilla LDAP functions and pam_ldap/nss_ldap
only use OpenLDAP functions. This would likely require a bit of work to
the Thunderbird makefiles to make it work and make it portable, and
probably some work to the Mozilla LDAP builds. If it requires work to
pam or nss, it's likely a non-starter.
Would it work to change TBird to dynamically load the Mozilla libldap?
I don't know what the "search order" is when a symbol is defined in more
than one shared object, but I would guess that the most recently loaded
one would be used. It is somewhat annoying but perhaps inevitable that
the OpenLDAP code is now considered a "system library" (it would be
better if it wasn't dragged into unexpecting applications by things like
PAM modules). Oh well.
I would eventually like to unify the Mozilla and OpenLDAP APIs. The
easiest way would be to change or extend the semantics of the Mozilla
API to match the OpenLDAP API. Much harder would be to make OpenLDAP
use NSS for crypto and change its semantics to match Mozilla's. It's
ironic that work is underway to make OpenLDAP use gnutls for crypto . .
. but perhaps the result of that work will make it easier to make
OpenLDAP use NSS.
Does anyone know if there will be a push to make TBird and other Mozilla
applications use GnuTLS? If so, I hate to say it but that may be
another reason to switch to OpenLDAP's client libraries.
The first step in possibly resolving the Mozilla vs. OpenLDAP API
differences would be to develop a test suite and/or analyze the
differences. Not a trivial task, and unfortunately probably not one
anyone has time to do.
-Mark
_______________________________________________
dev-tech-ldap mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-tech-ldap
