[Pkg-openldap-devel] Bug#725153: Bug#725153: Bug#725153: migrate to libnss3

[Alister Winfield]

My 2p worth. Just a reminder interactions between packages and ssl libraries can be a 'nightmare' especially dynamic modules. Anything that depends on <pick your favourite SSL library> then getting a 'different' but API almost compatible SSL lib loaded by pulling in a module is destined to crash and burn in a variety of entertaining ways.

Classic case is NSS_LDAP which is okay if there is a caching daemon running but 'other packages' fail to start if its not. Spotting the cause can take a while until its bitten you enough times.

On 8 Oct 2013, at 12:16, Timo Aaltonen <tjaalton at ubuntu.com> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07.10.2013 06:36, Steve Langasek wrote:
>> On Wed, Oct 02, 2013 at 08:36:23AM +0300, Timo Aaltonen wrote:
>>> Package: openldap Version: 2.4.31-1+nmu2 Severity: wishlist
>> 
>>> I'd like to migrate openldap to build against the NSS libs, in
>>> order to support features on 389ds where it is acting as an SSL
>>> client (replication etc) and expects NSS. 389 depends on libldap,
>>> but when it's built against gnutls things break.
>> 
>>> Licensing-wise it's not an issue, since NSS is dual-licensed 
>>> MPL-1.1/LGPL-2.1 so they're compatible.
>> 
>> Right; if this were LGPL-3 it would be a problem, but LGPL-2.1
>> keeps us compatible with all reverse-dependencies.
>> 
>> Upstream has recently commented about NSS being worse than gnutls.
>> Considering upstream has also expressed dissatisfaction with
>> gnutls itself, I wonder how bad NSS is to warrant such a reaction.
>> Are you aware of any compatibility problems with *other* packages,
>> when using libldap built against NSS?
> 
> I'm not aware of such bugs
> 
>> I have thought about switching us over to using NSS, because it
>> seems that it would solve the various stupid gnutls/gcrypt library
>> initialization bugs, which are otherwise only solvable with gnutls
>> by upgrading to a version that uses nettle in place of gcrypt - and
>> that in turn brings other license compatibility problems.
>> 
>> I've also considered whether we should do two separate builds of
>> libldap, one for internal consumption by slapd (probably statically
>> linking) and using OpenSSL, and one for use by third-party packages
>> and using a license-compatible TLS implementation... whether that's
>> gnutls, or NSS.  If NSS is a suitable implementation to use for
>> libldap generally (even if not for slapd), that would seem to be
>> the best option to solve both the 389ds bug and get us away from a
>> stale version of gnutls.
> 
> Yeah, that would probably be the best approach. Reading the list
> archives it sounds like with all the faults NSS would still be better
> than gnutls..
> 
> 
> - -- 
> t
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> 
> iQIcBAEBAgAGBQJSU+l5AAoJEMtwMWWoiYTc3+UQAJs04IlL/MqYFc0AFfF6HzRt
> rnRYIXbiIZbxk0qaxUqLzw5J+0zHp7XZaH+89Vl2I2xtJudhuRzoAuk/C+AZyhXk
> 1T4rvK8fENXZwjyj/xD13XaWl0RqBc8MDyArGCwRA9O9BycwQ+qw6+kkEsDNgQ9/
> 0sfoVrCLfXmTTdJruw/ayPSVuFOU483K9iv641xN4kFfXkKOydbvGinzYu3oi39H
> bkET6KXpdIisZCHjKAVaVA/WfRDAopnzeS0tu7DLhn9cysOsTfWHkTeq7w0XigkA
> QElM0Bnqm++Iodep+e8aql0NnI8+S5PaA0bJyMgfmJWBoMQRX7P8KGRJ1J74LWFQ
> Ok4Mz+ero06nIBsk8EKVKycUtg5v2ldYVNWYu+6MvWTJnK/ncx6GnJMbU6dAiIxK
> E/jfV/Tra0qddoNGvqo/m/7Y4/Vk4uUx2xP4jDK2gpDQowRJG7ee0UpcdQ+kPpVk
> aU/X92nv96HpzzGs9I+Pz+FbSmiuAVrOF6ICarOdoFXctGK7A/p5BHv2P3LPc8Qd
> tsdiCK2EciQzNP/ilhSXVHouZRB/64x7a6rv9IUz7kJeh46D8p6gxXOEjuAAc5Zm
> TNW1hmi38dcxrp0TdqIPpQNu5gq1POCtgK5YEeK6GtnDBFnE1O/uFSEWAI0Kw4rb
> BH+NEVMzDKFg9rIarZPj
> =oMu5
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Pkg-openldap-devel mailing list
> Pkg-openldap-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-openldap-devel