Horton

Re: Support for NSS as a libpq TLS backend

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Daniel Gustafsson <daniel@yesql.se>, Andres Freund <andres@anarazel.de>, Julien Rouhaud <rjuju123@gmail.com>, Jacob Champion <pchampion@vmware.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "hlinnaka@iki.fi" <hlinnaka@iki.fi>, "andrew.dunstan@2ndquadrant.com" <andrew.dunstan@2ndquadrant.com>, "michael@paquier.xyz" <michael@paquier.xyz>, "thomas.munro@gmail.com" <thomas.munro@gmail.com>, "sfrost@snowman.net" <sfrost@snowman.net>
Date: 2022-02-03T19:33:37Z
Lists: pgsql-hackers 
On Thu, Feb 3, 2022 at 2:16 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
> If we want simply an alternative, we had a GnuTLS variant almost done a
> few years ago, but in the end people didn't want it enough.  It seems to
> be similar now.

Yeah. I think it's pretty clear that the only real downside of
committing support for GnuTLS or NSS or anything else is that we then
need to maintain that support (or eventually remove it). I don't
really see a problem if Daniel wants to commit this, set up a few
buildfarm animals, and fix stuff when it breaks. If he does that, I
don't see that we're losing anything. But, if he commits it in the
hope that other people are going to step up to do the maintenance
work, maybe that's not going to happen, or at least not without
grumbling. I'm not objecting to this being committed in the sense that
I don't ever want to see it in the tree, but I'm also not volunteering
to maintain it.

As a philosophical matter, I don't think it's great for us - or the
Internet in general - to be too dependent on OpenSSL. Software
monocultures are not great, and OpenSSL has near-constant security
updates and mediocre documentation. Now, maybe anything else we
support will end up having similar issues, or worse. But if we and
other projects are never willing to support anything but OpenSSL, then
there will never be viable alternatives to OpenSSL, because a library
that isn't actually used by the software you care about is of no use.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

  1. Add tab-completion for CREATE FOREIGN TABLE.

  2. Add tap tests for the schema publications.

  3. Move Perl test modules to a better namespace

  4. Adjust configure to insist on Perl version >= 5.8.3.

  5. Simplify code related to compilation of SSL and OpenSSL

  6. Introduce --with-ssl={openssl} as a configure option

  7. Implement support for bulk inserts in postgres_fdw

  8. Fix redundant error messages in client tools

  9. doc: Apply more consistently <productname> markup for OpenSSL

  10. Check ssl_in_use flag when reporting statistics