Bug#725153: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls
Control: tag -1 = patch On Sat, Apr 09, 2016 at 06:10:16PM +0300, Timo Aaltonen wrote: 09.04.2016, 09:12, Ryan Tandy kirjoitti: What happens if both copies of libldap somehow end up linked into the same process? I don't know freeipa well enough to imagine a specific scenario, but it probably involves PAM somehow... Looks like curl handles this via renaming the symbol versions, we could probably do the same, if needed. Hmm right, I didn't notice the symbol renaming in curl though I used it as an example for how to build separate versions.. so it just needs changes in .symbols? The versioning script needs a change: http://sources.debian.net/src/curl/7.47.0-1/lib/libcurl.vers.in/ I'm not sure where that gets replaced, but that's what needs to be set. And then, yes, symbols needs to be updated to match. In our case, OpenLDAP upstream doesn't use symbol versioning, so our version script is in debian/patches/libldap-symbol-versions. Should be ABI compatible, which comment are you referring to? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725153#60 Well, my quick testing shows that a simple library swap isn't enough, but 389 probably needs a rebuild against the new lib. Doesn't matter anyway, if we're changing the symbol versions it's no longer hot-swappable, and I think changing those is probably safer.
Bug#725153: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls
09.04.2016, 09:12, Ryan Tandy kirjoitti: > On Fri, Apr 08, 2016 at 08:41:01PM +0300, Timo Aaltonen wrote: > Are you planning to do this in unstable as well, or just in xenial (as > it sounds like it might be a temporary measure)? Luca and I talked about > binNEW a while back, and flagged the out-of-date debian/copyright and > remaining lintian errors as possible concerns that might slow that down. I think it would be more permanent than that, as it's still useful for non-freeipa multimaster 389ds installations, and also test-suites using ldaps (both 389 & freeipa). > Adding libldap-common probably resolves #330695. I don't remember > whether there was anything else to be done for that one. Ah, I can look into that some more. > The dh_auto_configure invocation you have looks like it breaks stage1 > builds (unconditional --enable-slapd). Indeed, I'll fix that. > I notice the ITS#7373 patch hasn't been applied upstream yet. If we're > going to apply the NSS patches to both source trees, maybe you could > ping them for a review? Oh right, well for now this could be applied only to the nss tree. The other patches should only touch tls_n.c iirc.. will double-check that. > What happens if both copies of libldap somehow end up linked into the > same process? I don't know freeipa well enough to imagine a specific > scenario, but it probably involves PAM somehow... Looks like curl > handles this via renaming the symbol versions, we could probably do the > same, if needed. Hmm right, I didn't notice the symbol renaming in curl though I used it as an example for how to build separate versions.. so it just needs changes in .symbols? > I had anticipated a second out-of-tree build with the same source, so > now I'm curious: what required copying the source tree? It looks like > nss-build.patch is just changing the filename of the shared library, not > the SONAME or anything, right? (Should it? Or are they actually > ABI-compatible? From an earlier comment of yours, it sounded like they > might not be.) Well I used curl as an example.. but now that you mentioned it maybe it could just be configured without nss-build.diff and then again with it applied. Should be ABI compatible, which comment are you referring to? > What does the NSS build do with the TLS_CACERT setting we put in the > default ldap.conf? I notice #726116 is still open. Good point, didn't notice that until now.. > Best of luck getting freeipa working, by one approach or the other... it works great, just blocked on getting pkcs11 support in bind9, and native systemd units for apache2 & opendnssec... -- t signature.asc Description: OpenPGP digital signature
Bug#725153: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls
08.04.2016, 20:41, Timo Aaltonen kirjoitti: > 03.04.2016, 12:32, Timo Aaltonen kirjoitti: >> 20.05.2015, 20:43, Ryan Tandy kirjoitti: >>> Hi dkg, >>> >>> On Wed, May 20, 2015 at 12:58:08PM -0400, Daniel Kahn Gillmor wrote: If the work to switch openldap to NSS is strictly because of licensing concerns that have been resolved since the bug was opened, please reconsider the switch. >>> >>> I don't think anyone intends to switch the default libldap or slapd to >>> nss. I personally would argue against causing that kind of upgrade pain. >>> There's still a possibility of providing an alternate libldap built with >>> nss, but that would take some work, and it sounds like freeipa upstream >>> are moving away from needing it anyway. So this bug will probably just >>> go away eventually. >> >> Another thing is that folks using just 389ds can't replicate it (LP: >> #1564179) because of the same reason.. so having a libldap built against >> nss would still be useful for some. > > It is done! Or at least available for review: > > http://anonscm.debian.org/cgit/users/tjaalton/openldap.git/commit/?h=nss2 In order to minimize the diff, ldap.conf could still be shipped by libldap-2.4-2, and -nss can just depend on that. Avoids having another single-file package in the archive. -- t
Bug#725153: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls
Hi, On Mittwoch, 20. Mai 2015, Ryan Tandy wrote: > My understanding was that motivation for the request was wanting to > provide a fully-featured freeipa server in Debian, while some of its > features (specifically replication) only work properly when using > libldap built with nss. actually, it's just replication which isn't working with freeipa and openldap as it is in Debian. so I've just filed "#786411: replication doesnt work, how to get it to work..." to document and track down that issue properly. cheers, Holger signature.asc Description: This is a digitally signed message part.
Bug#725153: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls
Hi dkg, On Wed, May 20, 2015 at 12:58:08PM -0400, Daniel Kahn Gillmor wrote: https://bugs.debian.org/725153 suggests moving openldap's TLS backend in debian from gnutls to nss. The reasons given appear to be the older gnutls/gcrypt suid problem (which is quite a serious concern, particularly for libpam_ldap), and that newer gnutls/nettle introduces some licensing issues. My understanding was that motivation for the request was wanting to provide a fully-featured freeipa server in Debian, while some of its features (specifically replication) only work properly when using libldap built with nss. The licensing issues have been resolved by nettle relicensing to LGPL 3+ or GPL 2+, effective in nettle 3.0: http://mid.gmane.org/nnd2el5d8h@bacon.lysator.liu.se Since 2.4.40-1 (in jessie) we already build with gnutls28 and nettle, based on libgmp having changed its license (#745231), but jessie only has nettle 2.7. I hope I didn't introduce a licensing problem by doing that? IIUC we take gmp as GPLv2+, nettle as LGPLv2.1+, and gnutls as LGPLv2.1+, so the combination should be compatible with GPLv2+. If the work to switch openldap to NSS is strictly because of licensing concerns that have been resolved since the bug was opened, please reconsider the switch. I don't think anyone intends to switch the default libldap or slapd to nss. I personally would argue against causing that kind of upgrade pain. There's still a possibility of providing an alternate libldap built with nss, but that would take some work, and it sounds like freeipa upstream are moving away from needing it anyway. So this bug will probably just go away eventually. hope that helps, Ryan -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
