Re: Support for NSS as a libpq TLS backend

Greetings,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Tue, Feb 1, 2022 at 01:52:09PM -0800, Andres Freund wrote:
> > There's https://hg.mozilla.org/projects/nspr/file/tip/pr/src - which is I
> > think the upstream source.
> >
> > A project without even a bare-minimal README at the root does have a "internal
> > only" feel to it...
>
> I agree --- it is a library --- if they don't feel the need to publish
> the API, it seems to mean they want to maintain the ability to change it
> at any time, and therefore it is inappropriate for other software to
> rely on that API.

This is really not a reasonable representation of how this library has
been maintained historically nor is there any reason to think that their
policy regarding the API has changed recently. They do have a
documented API and that hasn't changed- it's just that it's not easily
available in web-page form any longer and that's due to something
independent of the library maintenance. They've also done a good job
with maintaining the API as one would expect from a library and so this
really isn't a reason to avoid using it. If there's actual specific
examples of the API not being well maintained and causing issues then
please point to them and we can discuss if that is a reason to consider
not depending on NSS/NSPR.

> This is not the same as Postgres extensions needing to read the Postgres
> source code --- they are an important but edge use case and we never saw
> the need to standardize or publish the internal functions that must be
> studied and adjusted possibly for major releases.

I agree that extensions and public libraries aren't entirely the same
but I don't think it's all that unreasonable for developers that are
using a library to look at the source code for that library when
developing against it, that's certainly something I've done for a
number of different libraries.

> This kind of feels like the Chrome JavaScript code that used to be able
> to be build separately for PL/v8, but has gotten much harder to do in
> the past few years.

This isn't at all like that case, where the maintainers made a very
clear and intentional choice to make it quite difficult for packagers to
pull v8 out to package it. Nothing like that has happened with NSS and
there isn't any reason to think that it will based on what the
maintainers have said and what they've done across the many years that
NSS has been around.

Thanks,

Stephen