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 <tjaal...@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-de...@lists.alioth.debian.org > http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-openldap-devel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
