Re: Support for NSS as a libpq TLS backend

> On 31 Jan 2022, at 17:24, Stephen Frost <sfrost@snowman.net> wrote:
> * Daniel Gustafsson (daniel@yesql.se) wrote:

>> I'm counting this and Andres' comment as a -1 on the patchset, and given where
>> we are in the cycle I'm mark it rejected in the CF app shortly unless anyone
>> objects.
>
> I agree that it's concerning to hear that OpenLDAP dropped support for
> NSS... though I don't seem to be able to find any information as to why
> they decided to do so.

I was also unable to do that.  There is no information that I could see in
either the commit message, Bugzilla entry (#9207) or on the mailinglist.
Searching the web didn't yield anything either.  I've reached out to hopefully
get a bit more information.

> I'm also very much a fan of having an alternative to OpenSSL and the
> NSS/NSPR license fits well for us, unlike the alternatives to OpenSSL
> used by other projects, such as GnuTLS (which is the alternative to
> OpenSSL that OpenLDAP now has) or other libraries like wolfSSL.

Short of platform specific (proprietary) libraries like Schannel and Secure
Transport, the alternatives are indeed slim.

> Beyond the documentation issue, which I agree is a concern but also
> seems to be actively realized as an issue by the NSS/NSPR folks,

It is, but it has also been an issue for years to be honest, getting the docs
up to scratch will require a very large effort.

> is there some other reason that the curl folks are thinking of dropping support
> for it?

It's also not really used anymore in conjunction with curl, with Red Hat no
longer shipping builds against it.

--
Daniel Gustafsson        https://vmware.com/