Debian Bug report logs - #725153
migrate to libnss3

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@ubuntu.com>

To: submit@bugs.debian.org

Subject: migrate to libnss3

Date: Wed, 02 Oct 2013 08:36:23 +0300

Package: openldap
Version: 2.4.31-1+nmu2
Severity: wishlist

	Hi

  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.

The ultimate goal is to eventually provide full FreeIPA server
experience on Debian.

Message #10 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Timo Aaltonen <tjaalton@ubuntu.com>, 725153@bugs.debian.org

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

Date: Sun, 6 Oct 2013 20:36:01 -0700

[Message part 1 (text/plain, inline)]

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

Thanks,
-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Quanah Gibson-Mount <quanah@zimbra.com>

To: Steve Langasek <vorlon@debian.org>, 725153@bugs.debian.org

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

Date: Mon, 07 Oct 2013 15:03:02 -0700

--On Sunday, October 06, 2013 8:36 PM -0700 Steve Langasek 
<vorlon@debian.org> wrote:

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

Hi Steve,

There's some discussion about MozNSS (and initialization in fact...) here:

<http://www.openldap.org/lists/openldap-devel/201204/threads.html>

Specifically the thread on "proposal, library error codes for TLS failures"

Regards,
Quanah

--

Quanah Gibson-Mount
Architect - Server
Zimbra Software, LLC
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Message #20 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@ubuntu.com>

To: Steve Langasek <vorlon@debian.org>, 725153@bugs.debian.org

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

Date: Tue, 08 Oct 2013 14:16:09 +0300

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

Message #25 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Alister Winfield <alister@ticklers.org>

To: Timo Aaltonen <tjaalton@ubuntu.com>, 725153@bugs.debian.org

Cc: Steve Langasek <vorlon@debian.org>

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

Date: Tue, 8 Oct 2013 12:30:46 +0100

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@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@lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-openldap-devel

Message #30 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Quanah Gibson-Mount <quanah@zimbra.com>

To: 725153@bugs.debian.org, Timo Aaltonen <tjaalton@ubuntu.com>

Cc: Steve Langasek <vorlon@debian.org>

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

Date: Tue, 08 Oct 2013 13:15:03 -0700

--On Tuesday, October 08, 2013 12:30 PM +0100 Alister Winfield 
<alister@ticklers.org> wrote:

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

Yes, I remember the issues caused by openssl and gnutls both being loaded 
up into the symbol space from the past as well.

Also, I would carefully consider the negative security implications of 
using MozNSS as detailed in the  thread I listed.

--Quanah

--

Quanah Gibson-Mount
Architect - Server
Zimbra Software, LLC
--------------------
Zimbra ::  the leader in open source messaging and collaboration

Message #35 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: debian-backports@lists.debian.org, 725153@bugs.debian.org

Cc: Debian FreeIPA Team <pkg-freeipa-devel@lists.alioth.debian.org>

Subject: Re: [Pkg-freeipa-devel] freeipa-server backport to Jessie?

Date: Wed, 15 Apr 2015 18:45:39 +0200

[Message part 1 (text/plain, inline)]

Hi,

this has become off-topic for debian-backports so please don't include debian-
backports@lists.debian.org in your replies.

On Mittwoch, 15. April 2015, Holger Levsen wrote:
> On Mittwoch, 15. April 2015, Timo Aaltonen wrote:
> > That's "separate libldap built against nss" again.. I'm not going to put
> > effort on that anymore, and it wouldn't help jessie either.

to build the openldap package against libnss3-dev, one has to:

- in debian/control: replace the build-dependency on libgnutls28-dev with 
libnss3-dev
- in debian/configure.options: use --with-tls=moznss (instead of --with-tls) 
and also add the line "CPPFLAGS=-I/usr/include/nss\ -I/usr/include/nspr 
LDFLAGS=-L/usr/lib/x86_64-linux-gnu/nss" somewhere.

With that the build still fails with

smbk5pwd.c:1073:4: warning: too many arguments for format [-Wformat-extra-
args]
smbk5pwd.c:968:2: warning: variable 'dummy_ad' set but not used [-Wunused-but-
set-variable]
  dummy_ad;
  ^
Makefile:50: recipe for target 'smbk5pwd.lo' failed
make[2]: *** [smbk5pwd.lo] Error 1
make[2]: Leaving directory './openldap-2.4.40+dfsg/contrib/slapd-
modules/smbk5pwd'

but that should be easy to work around by not building the slapd packages or 
contrib modules (as freeipa-server users wont need slapd anyway...)

I haven't done this now, but will update this bug once I've done so. (Which 
might take some weeks...)


cheers,
	Holger

[signature.asc (application/pgp-signature, inline)]

Message #40 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: 725153@bugs.debian.org, pkg-freeipa-devel@lists.alioth.debian.org

Subject: Re: [Pkg-freeipa-devel] freeipa-server backport to Jessie?

Date: Wed, 15 Apr 2015 21:31:17 +0300

On 15.04.2015 19:45, Holger Levsen wrote:
> Hi,
>
> this has become off-topic for debian-backports so please don't include debian-
> backports@lists.debian.org in your replies.
>
> On Mittwoch, 15. April 2015, Holger Levsen wrote:
>> On Mittwoch, 15. April 2015, Timo Aaltonen wrote:
>>> That's "separate libldap built against nss" again.. I'm not going to put
>>> effort on that anymore, and it wouldn't help jessie either.
>
> to build the openldap package against libnss3-dev, one has to:
>
> - in debian/control: replace the build-dependency on libgnutls28-dev with
> libnss3-dev
> - in debian/configure.options: use --with-tls=moznss (instead of --with-tls)
> and also add the line "CPPFLAGS=-I/usr/include/nss\ -I/usr/include/nspr
> LDFLAGS=-L/usr/lib/x86_64-linux-gnu/nss" somewhere.
>
> With that the build still fails with
>
> smbk5pwd.c:1073:4: warning: too many arguments for format [-Wformat-extra-
> args]
> smbk5pwd.c:968:2: warning: variable 'dummy_ad' set but not used [-Wunused-but-
> set-variable]
>    dummy_ad;
>    ^
> Makefile:50: recipe for target 'smbk5pwd.lo' failed
> make[2]: *** [smbk5pwd.lo] Error 1
> make[2]: Leaving directory './openldap-2.4.40+dfsg/contrib/slapd-
> modules/smbk5pwd'
>
> but that should be easy to work around by not building the slapd packages or
> contrib modules (as freeipa-server users wont need slapd anyway...)
>
> I haven't done this now, but will update this bug once I've done so. (Which
> might take some weeks...)

You probably need the Fedora patches too:

http://pkgs.fedoraproject.org/cgit/openldap.git/commit/?id=592250ebfbcc7aa47f22bf1f8613fe20f33fd39a

Message #45 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: 725153@bugs.debian.org, pkg-freeipa-devel@lists.alioth.debian.org

Subject: Re: [Pkg-openldap-devel] Bug#725153: [Pkg-freeipa-devel] freeipa-server backport to Jessie?

Date: Thu, 16 Apr 2015 16:32:54 -0700

[Message part 1 (text/plain, inline)]

On Wed, Apr 15, 2015 at 06:45:39PM +0200, Holger Levsen wrote:
>to build the openldap package against libnss3-dev, one has to:
>
>- in debian/control: replace the build-dependency on libgnutls28-dev with
>libnss3-dev
>- in debian/configure.options: use --with-tls=moznss (instead of --with-tls)
>and also add the line "CPPFLAGS=-I/usr/include/nss\ -I/usr/include/nspr
>LDFLAGS=-L/usr/lib/x86_64-linux-gnu/nss" somewhere.
>
>With that the build still fails with
>
>smbk5pwd.c:1073:4: warning: too many arguments for format [-Wformat-extra-
>args]
>smbk5pwd.c:968:2: warning: variable 'dummy_ad' set but not used [-Wunused-but-
>set-variable]
>  dummy_ad;
>  ^
>Makefile:50: recipe for target 'smbk5pwd.lo' failed
>make[2]: *** [smbk5pwd.lo] Error 1
>make[2]: Leaving directory './openldap-2.4.40+dfsg/contrib/slapd-
>modules/smbk5pwd'
>
>but that should be easy to work around by not building the slapd packages or
>contrib modules (as freeipa-server users wont need slapd anyway...)

The attached debdiff replaces gnutls with nss but continues building 
smbk5pwd with nettle. AFAICT the result works properly, smbk5pwd 
included.

I didn't try importing Fedora's patches, but noted that several were 
upstreamed already, and more were submitted and await review.

Looks like Debian's nss doesn't support loading PEM certificates at 
runtime yet: #726116. My knee-jerk reaction is that I dislike the idea 
of changing the default libldap to moznss before resolving that. 
Migrating slapd's server certificates and CA certificates mentioned in 
ldap.conf is possible, with some work; but we'd also be breaking any 
clients configured for particular PEM certificates. It would be a lot 
nicer if existing setups could keep working.

I only spent a few minutes on this, didn't look yet at whether building 
a second libldap for freeipa's use is feasible. Timo, how far did you 
get on that when you looked at it previously?

Also, do you know anything about the thought process behind the recent 
(and then reverted) switch to openssl in Fedora? Are they planning to 
move away from moznss?

[openldap_2.4.40+dfsg-1+moznss.debdiff (text/plain, attachment)]

Message #50 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>, 725153@bugs.debian.org, pkg-freeipa-devel@lists.alioth.debian.org

Subject: Re: [Pkg-freeipa-devel] [Pkg-openldap-devel] Bug#725153: freeipa-server backport to Jessie?

Date: Fri, 17 Apr 2015 07:45:24 +0300

On 17.04.2015 02:32, Ryan Tandy wrote:
> On Wed, Apr 15, 2015 at 06:45:39PM +0200, Holger Levsen wrote:
>> to build the openldap package against libnss3-dev, one has to:
>>
>> - in debian/control: replace the build-dependency on libgnutls28-dev with
>> libnss3-dev
>> - in debian/configure.options: use --with-tls=moznss (instead of
>> --with-tls)
>> and also add the line "CPPFLAGS=-I/usr/include/nss\ -I/usr/include/nspr
>> LDFLAGS=-L/usr/lib/x86_64-linux-gnu/nss" somewhere.
>>
>> With that the build still fails with
>>
>> smbk5pwd.c:1073:4: warning: too many arguments for format
>> [-Wformat-extra-
>> args]
>> smbk5pwd.c:968:2: warning: variable 'dummy_ad' set but not used
>> [-Wunused-but-
>> set-variable]
>>  dummy_ad;
>>  ^
>> Makefile:50: recipe for target 'smbk5pwd.lo' failed
>> make[2]: *** [smbk5pwd.lo] Error 1
>> make[2]: Leaving directory './openldap-2.4.40+dfsg/contrib/slapd-
>> modules/smbk5pwd'
>>
>> but that should be easy to work around by not building the slapd
>> packages or
>> contrib modules (as freeipa-server users wont need slapd anyway...)
> 
> The attached debdiff replaces gnutls with nss but continues building
> smbk5pwd with nettle. AFAICT the result works properly, smbk5pwd included.
> 
> I didn't try importing Fedora's patches, but noted that several were
> upstreamed already, and more were submitted and await review.
> 
> Looks like Debian's nss doesn't support loading PEM certificates at
> runtime yet: #726116. My knee-jerk reaction is that I dislike the idea
> of changing the default libldap to moznss before resolving that.
> Migrating slapd's server certificates and CA certificates mentioned in
> ldap.conf is possible, with some work; but we'd also be breaking any
> clients configured for particular PEM certificates. It would be a lot
> nicer if existing setups could keep working.
> 
> I only spent a few minutes on this, didn't look yet at whether building
> a second libldap for freeipa's use is feasible. Timo, how far did you
> get on that when you looked at it previously?

Actually, I pushed a hacked up libldap to my openldap git on alioth
yesterday, but forgot to update this bug, oops

git://git.debian.org/git/users/tjaalton/openldap.git

it doesn't build anything other than libldap & ldap-utils, and includes
the applicable Fedora patches (yes three of them were upstream already)
minus autoconf one which gave me some pain. If it's ok for you, we could
have a branch on the official pkg repo so folks that need to build their
own packages could use that as the base.

I don't think fixing this bug by switching to build against moznss makes
much sense for Debian, because the need for it is going away once
Freeipa ditches using ldap+tls connections altogether which is currently
only used in the replication process. Once that's rewritten and using
GSSAPI (in 4.2?) we'd be fine.

That might still leave plain 389-ds-base multimaster replication in the
dust though, but I'm not interested in that personally.. Building a
second libldap against moznss might be possible, but looks icky..

> Also, do you know anything about the thought process behind the recent
> (and then reverted) switch to openssl in Fedora? Are they planning to
> move away from moznss?

Nah I guess that was some kind of frustration by the maintainer, did
that without any discussion and it caused some "concern" on #freeipa at
the time :)


-- 
t

Message #55 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: Timo Aaltonen <tjaalton@debian.org>

Cc: 725153@bugs.debian.org, pkg-freeipa-devel@lists.alioth.debian.org

Subject: Re: [Pkg-freeipa-devel] [Pkg-openldap-devel] Bug#725153: freeipa-server backport to Jessie?

Date: Fri, 17 Apr 2015 11:54:11 -0700

On Fri, Apr 17, 2015 at 07:45:24AM +0300, Timo Aaltonen wrote:
>Actually, I pushed a hacked up libldap to my openldap git on alioth
>yesterday, but forgot to update this bug, oops
>
>git://git.debian.org/git/users/tjaalton/openldap.git
>
>it doesn't build anything other than libldap & ldap-utils, and includes
>the applicable Fedora patches (yes three of them were upstream already)
>minus autoconf one which gave me some pain. If it's ok for you, we could
>have a branch on the official pkg repo so folks that need to build their
>own packages could use that as the base.

Something like a "moznss" branch parallel to master? I don't have any 
problem with that.

FWIW, the autoconf patch worked for me once I added Build-Depends: 
pkg-config.

>I don't think fixing this bug by switching to build against moznss makes
>much sense for Debian, because the need for it is going away once
>Freeipa ditches using ldap+tls connections altogether which is currently
>only used in the replication process. Once that's rewritten and using
>GSSAPI (in 4.2?) we'd be fine.

OK.

>That might still leave plain 389-ds-base multimaster replication in the
>dust though, but I'm not interested in that personally.. Building a
>second libldap against moznss might be possible, but looks icky..

Icky indeed. Based on what you wrote above, sounds like that probably 
won't be worth the effort, if it won't be needed in future.

So as I understand it: this bug is basically wontfix in the official 
package at this point; you're (already?) providing an unofficial 
nss-libldap that freeipa users can drop in to replace the 
gnutls-libldap; and nothing has to be rebuilt to take advantage of that. 
Do I have that right?

Message #60 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>

Cc: pkg-freeipa-devel@lists.alioth.debian.org, 725153@bugs.debian.org

Subject: Re: [Pkg-freeipa-devel] [Pkg-openldap-devel] Bug#725153: freeipa-server backport to Jessie?

Date: Tue, 21 Apr 2015 14:12:18 +0300

On 17.04.2015 21:54, Ryan Tandy wrote:
> On Fri, Apr 17, 2015 at 07:45:24AM +0300, Timo Aaltonen wrote:
>> Actually, I pushed a hacked up libldap to my openldap git on alioth
>> yesterday, but forgot to update this bug, oops
>>
>> git://git.debian.org/git/users/tjaalton/openldap.git
>>
>> it doesn't build anything other than libldap & ldap-utils, and includes
>> the applicable Fedora patches (yes three of them were upstream already)
>> minus autoconf one which gave me some pain. If it's ok for you, we could
>> have a branch on the official pkg repo so folks that need to build their
>> own packages could use that as the base.
> 
> Something like a "moznss" branch parallel to master? I don't have any
> problem with that.

Ok, I'll push something at some point.

> FWIW, the autoconf patch worked for me once I added Build-Depends:
> pkg-config.

ha, stupid me then.. the error message I got wasn't too obvious

>> That might still leave plain 389-ds-base multimaster replication in the
>> dust though, but I'm not interested in that personally.. Building a
>> second libldap against moznss might be possible, but looks icky..
> 
> Icky indeed. Based on what you wrote above, sounds like that probably
> won't be worth the effort, if it won't be needed in future.
> 
> So as I understand it: this bug is basically wontfix in the official
> package at this point; you're (already?) providing an unofficial
> nss-libldap that freeipa users can drop in to replace the
> gnutls-libldap; and nothing has to be rebuilt to take advantage of that.
> Do I have that right?

Well, my quick testing shows that a simple library swap isn't enough,
but 389 probably needs a rebuild against the new lib. Or replication
fails because of something unrelated to this.. don't have much time to
test anything in the next couple of weeks.


-- 
t

Message #65 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

To: 725153@bugs.debian.org

Subject: openldap, nss, and gnutls

Date: Wed, 20 May 2015 12:58:08 -0400

[Message part 1 (text/plain, inline)]

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.

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.fsf@bacon.lysator.liu.se

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.

Regards,

          --dkg

[signature.asc (application/pgp-signature, inline)]

Message #70 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, 725153@bugs.debian.org

Subject: Re: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls

Date: Wed, 20 May 2015 10:43:23 -0700

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

Message #75 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 725153@bugs.debian.org, Ryan Tandy <ryan@nardis.ca>

Cc: Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: Bug#725153: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls

Date: Thu, 21 May 2015 14:45:44 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #82 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>, 725153@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: [Pkg-openldap-devel] Bug#725153: Bug#725153: openldap, nss, and gnutls

Date: Sun, 3 Apr 2016 12:32:46 +0300

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.



-- 
t

Message #87 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>, 725153@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: [Pkg-openldap-devel] Bug#725153: Bug#725153: Bug#725153: openldap, nss, and gnutls

Date: Fri, 8 Apr 2016 20:41:01 +0300

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

389-ds-base builds fine against it, but I haven't tested multimaster or
"traditional" freeipa replication with it yet.

I'd like to get this in Ubuntu 16.04 as a backup plan if the remaining
dependencies for freeipa 4.3.1 can't make it in time, so if you have
time to review the packaging within the next few days (!) that would be
awesome.


-- 
t

Message #92 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>, 725153@bugs.debian.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>

Subject: Re: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls

Date: Sat, 9 Apr 2016 08:52:38 +0300

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

Message #97 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: Timo Aaltonen <tjaalton@debian.org>, 725153@bugs.debian.org

Subject: Re: Bug#725153: openldap, nss, and gnutls

Date: Fri, 8 Apr 2016 23:12:16 -0700

[Message part 1 (text/plain, inline)]

On Fri, Apr 08, 2016 at 08:41:01PM +0300, Timo Aaltonen wrote:
>It is done! Or at least available for review:
>
>http://anonscm.debian.org/cgit/users/tjaalton/openldap.git/commit/?h=nss2

Cool!

>389-ds-base builds fine against it, but I haven't tested multimaster or
>"traditional" freeipa replication with it yet.
>
>I'd like to get this in Ubuntu 16.04 as a backup plan if the remaining
>dependencies for freeipa 4.3.1 can't make it in time, so if you have
>time to review the packaging within the next few days (!) that would be
>awesome.

The following comments are just from looking at the commit, I haven't 
built or tested it yet.

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.

Sorry about git master still being entangled with my unfinished 2.4.44 
update. Pushing that incomplete was a bad idea and I have been 
regretting it. I am trying to dedicate some time to it this weekend...

Adding libldap-common probably resolves #330695. I don't remember 
whether there was anything else to be done for that one.

The dh_auto_configure invocation you have looks like it breaks stage1 
builds (unconditional --enable-slapd).

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?

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.

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

What does the NSS build do with the TLS_CACERT setting we put in the 
default ldap.conf? I notice #726116 is still open.

Best of luck getting freeipa working, by one approach or the other...

[signature.asc (application/pgp-signature, inline)]

Message #102 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>, 725153@bugs.debian.org

Subject: Re: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls

Date: Sat, 9 Apr 2016 18:10:16 +0300

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, attachment)]

Message #107 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: Timo Aaltonen <tjaalton@debian.org>

Cc: 725153@bugs.debian.org

Subject: Re: [Pkg-openldap-devel] Bug#725153: openldap, nss, and gnutls

Date: Sat, 9 Apr 2016 09:19:46 -0700

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.

Message #114 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>, 725153@bugs.debian.org

Subject: Re: [Pkg-openldap-devel] Bug#725153: Bug#725153: openldap, nss, and gnutls

Date: Sun, 10 Apr 2016 12:11:40 +0300

09.04.2016, 19:19, Ryan Tandy kirjoitti:
> 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.

Ahh, ok.. so for moznss the .map files would have OPENLDAP-NSS_2.4_2 for
the NSS build. I've added that.

Btw, the tar & patch approach makes it easier to clean up afterwards.
Building from the same root would mean unapplying nss-build.diff on
clean and that might be fragile. Using quilt and keeping the patch last
on series makes adding patches to need a bit more work. But if you
prefer this more then I can make that happen.

I've pushed new commits to the branch trying to address all the things
you've mentioned. But looks like #726116 might make all of this too
early. That said, 389 and IPA do use their own certificate db's, but I'm
not sure if the systemwide certificates should be available to them. I
need to ask upstream.

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

Oh, that was when we were testing libldap-2.4-2 built against nss. I
don't know if it needed a rebuild.. maybe. But in this case that doesn't
matter as you said, it needs a rebuild in any case.

Thanks for the review and comments so far!

-- 
t

Message #119 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: Timo Aaltonen <tjaalton@debian.org>

Cc: 725153@bugs.debian.org

Subject: Re: [Pkg-openldap-devel] Bug#725153: Bug#725153: openldap, nss, and gnutls

Date: Sun, 10 Apr 2016 09:06:29 -0700

On Sun, Apr 10, 2016 at 12:11:40PM +0300, Timo Aaltonen wrote:
>Building from the same root would mean unapplying nss-build.diff on
>clean and that might be fragile. Using quilt and keeping the patch last
>on series makes adding patches to need a bit more work. But if you
>prefer this more then I can make that happen.

My preference for that was assuming we could build identical source with 
different options, but it looks like we have several reasons for using 
modified sources.

>I've pushed new commits to the branch trying to address all the things
>you've mentioned. But looks like #726116 might make all of this too
>early.

Ah. That's unfortunate.

The obvious workaround is to give the NSS build its own config file, 
with the ca-certificates.crt reference removed.  Not exactly ideal, and 
it causes us upgrade grief later on if we want to switch back to having 
the same file for both.

Actually gnutls28 is configured with a default trust store these days. I 
should look into whether that works with libldap and that default 
setting could be dropped. Not sure about upgraded systems though; we 
aren't supposed to modify conffiles in maintainer scripts, so we'd be 
relying on users to accept the change. Sounds fragile.

Message #124 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Timo Aaltonen <tjaalton@debian.org>

To: Ryan Tandy <ryan@nardis.ca>, 725153@bugs.debian.org

Subject: Re: [Pkg-openldap-devel] Bug#725153: Bug#725153: Bug#725153: openldap, nss, and gnutls

Date: Tue, 19 Apr 2016 10:08:12 +0300

10.04.2016, 19:06, Ryan Tandy kirjoitti:
> On Sun, Apr 10, 2016 at 12:11:40PM +0300, Timo Aaltonen wrote:
>> Building from the same root would mean unapplying nss-build.diff on
>> clean and that might be fragile. Using quilt and keeping the patch last
>> on series makes adding patches to need a bit more work. But if you
>> prefer this more then I can make that happen.
> 
> My preference for that was assuming we could build identical source with
> different options, but it looks like we have several reasons for using
> modified sources.
> 
>> I've pushed new commits to the branch trying to address all the things
>> you've mentioned. But looks like #726116 might make all of this too
>> early.
> 
> Ah. That's unfortunate.
> 
> The obvious workaround is to give the NSS build its own config file,
> with the ca-certificates.crt reference removed.  Not exactly ideal, and
> it causes us upgrade grief later on if we want to switch back to having
> the same file for both.
> 
> Actually gnutls28 is configured with a default trust store these days. I
> should look into whether that works with libldap and that default
> setting could be dropped. Not sure about upgraded systems though; we
> aren't supposed to modify conffiles in maintainer scripts, so we'd be
> relying on users to accept the change. Sounds fragile.

Ok, I've got some news and I think they're good: 389ds is working on
getting rid of the dependency on nss:

http://www.port389.org/docs/389ds/design/allow-usage-of-openldap-lib-w-openssl.html

and I've tested the patch and verified that replication with starttls
works now and uploaded it to unstable, so I'd say screw with libldap-nss
at this point :)



-- 
t

Message #129 received at 725153@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: 725153@bugs.debian.org

Subject: Re: Bug#725153: openldap, nss, and gnutls

Date: Sun, 15 Jan 2017 11:27:49 -0800

Control: tags -1 = wontfix

On Tue, Apr 19, 2016 at 10:08:12AM +0300, Timo Aaltonen wrote:
>Ok, I've got some news and I think they're good: 389ds is working on
>getting rid of the dependency on nss:
>
>http://www.port389.org/docs/389ds/design/allow-usage-of-openldap-lib-w-openssl.html
>
>and I've tested the patch and verified that replication with starttls
>works now and uploaded it to unstable, so I'd say screw with libldap-nss
>at this point :)

Setting back to wontfix based on that.

Message #136 received at 725153-close@bugs.debian.org (full text, mbox, reply):

From: Ryan Tandy <ryan@nardis.ca>

To: 725153-close@bugs.debian.org

Subject: Re: Bug#725153: openldap, nss, and gnutls

Date: Wed, 25 Mar 2020 19:41:53 -0700

On Sun, Jan 15, 2017 at 11:27:49AM -0800, Ryan Tandy wrote:
>Control: tags -1 = wontfix

And closing, there's no need to keep this one open.

Send a report that this bug log contains spam.