Re: Support for NSS as a libpq TLS backend

Greetings,

* Bruce Momjian (bruce(at)momjian(dot)us) wrote:
> On Thu, Feb 3, 2022 at 01:42:53PM -0500, Stephen Frost wrote:
> > * 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?

To be clear, *part* of the web-based documentation disappeared and
hasn't been replaced yet. The NSS-specific pieces are actually still
available, it's the NSPR (which is a lower level library used by NSS)
part that was removed from MDN and hasn't been brought back yet, but
which does still exist as comments in the source of the library.

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

Then I don't understand where the claim you made that "it seems to mean
they want to maintain the ability to change it at any time" has any
merit.

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

Because... it's documented? They have public (and private) .h files in
the source tree and the function declarations have large comment blocks
above them which provide a documented API. I'm not talking about having
to decipher from the actual C code what's going on but just reading the
function header comment that provides the documentation of the API for
each of the functions, and there's larger blocks of comments at the top
of those .h files which provide more insight into how the functions in
that particular part of the system work and interact with each other.
Maybe those things would be better as separate README files like what we
do, but maybe not, and I don't see it as a huge failing that they chose
to use a big comment block at the top of their .h files to explain
things rather than separate README files.

Reading comments in code that I'm calling out to, even if it's in
another library (or another part of PG where the README isn't helping me
enough, or due to there not being a README for that particular thing)
almost seems typical, to me anyway. Perhaps the exception being when
there are good man pages.

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

They have made public statements regarding this and it's been linked to
already in this thread:

https://github.com/mdn/content/issues/12471

where they explicitly state that the project is alive and maintained,
further, it now now also links to this:

https://bugzilla.mozilla.org/show_bug.cgi?id=1753127

Which certainly seems to have had a fair bit of action taken on it.

Indeed, it looks like they've got a lot of the docs up and online now,
including the documentation for the function that started much of this:

https://firefox-source-docs.mozilla.org/nspr/reference/pr_recv.html#pr-recv

Looks like they're still working out some of the kinks between the NSS
pages and having links from them over to the NSPR pages, but a whole lot
of progress sure looks like it's been made in pretty short order here.

Definitely isn't looking unmaintained to me.

Thanks,

Stephen