Re: Support for NSS as a libpq TLS backend

On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote:
> 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

So they have always been bad at providing an API, not just now, or that
their web content disappeared and they haven't fixed it, for how long?
I guess that is better than the v8 case, but not much. Is posting web
content really that hard for them?

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

I have no specifics.

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

Wow, you have a much higher tolerance than I do. How do you even know
which functions are the public API if you have to look at the source
code?

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

As far as I know, the v8 developers didn't say anything, they just
started moving things around to make it easier for them and harder for
packagers --- and they didn't care.

I frankly think we need some public statement from the NSS developers
before moving forward --- there are just too many red flags here, and
once we support it, it will be hard to remove support for it.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

If only the physical world exists, free will is an illusion.