How to resolve the Mozilla/OpenLDAP conflict?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

How to resolve the Mozilla/OpenLDAP conflict?

Rich Megginson
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.

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.

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.
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: How to resolve the Mozilla/OpenLDAP conflict?

Mark Smith-3
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-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird
Reply | Threaded
Open this post in threaded view
|

Re: How to resolve the Mozilla/OpenLDAP conflict?

Wolfgang Rosenauer-2
In reply to this post by Rich Megginson
Mark Smith wrote:

> 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.

a PAM module wouldn't be a problem but a nss module is :-(
TB is loading the mozldap dynamically but AFAIK you never know which
library is used to resolv a symbol. You can't expect that the latest
loaded one will be used and even if you could, then TB or nss_ldap will
use the wrong one.

> 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.

Why should mozilla switch to GnuTLS? I don't see advantages but only
disadvantages starting with the incompatible license.

> 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.

That's true. I'm going to try a quick and dirty fix to prefix every ldap
function so that symbols doesn't have the same name. That shouldn't be a
problem for just Thunderbird in a nutshell. It's not really a solution
though.

Wolfgang
_______________________________________________
dev-apps-thunderbird mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-thunderbird