Re: Support for NSS as a libpq TLS backend
Daniel Gustafsson <daniel@yesql.se>
From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jacob Champion <pchampion@vmware.com>,
"hlinnaka@iki.fi" <hlinnaka@iki.fi>,
"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>,
"andrew.dunstan@2ndquadrant.com" <andrew.dunstan@2ndquadrant.com>,
"thomas.munro@gmail.com" <thomas.munro@gmail.com>,
"sfrost@snowman.net" <sfrost@snowman.net>,
"andres@anarazel.de" <andres@anarazel.de>
Date: 2021-01-29T13:13:30Z
Lists: pgsql-hackers
> On 29 Jan 2021, at 07:01, Michael Paquier <michael@paquier.xyz> wrote: > > On Fri, Jan 29, 2021 at 12:20:21AM +0100, Daniel Gustafsson wrote: >> SSL is admittedly an obsolete technical term, but it's one that enough people >> have decided is interchangeable with TLS that it's not a hill worth dying on >> IMHO. Since postgres won't allow for using libnss or OpenSSL for cryptohash >> *without* compiling SSL/TLS support (used or not), I think --with-ssl=LIB is >> more descriptive and less confusing. > > Okay, let's use --with-ssl then for the new switch name. The previous > patch is backward-compatible, and will simplify the rest of the set, > so let's move on with it. Once this is done, my guess is that it > would be cleaner to have a new patch that includes only the > ./configure and MSVC changes, and then the rest: test refactoring, > cryptohash, strong random and lastly TLS (we may want to cut this a > bit more though and perhaps have some restrictions depending on the > scope of options a first patch set could support). > > I'll wait a bit first to see if there are any objections to this > change. I'm still not convinced that adding --with-ssl=openssl is worth it before the rest of NSS goes in (and more importantly, *if* it goes in). On the one hand, we already have pluggable (for some value of) support for adding TLS libraries, and adding --with-ssl is one more piece of that puzzle. We could of course have endless --with-X options instead but as you say, --with-uuid has set the tone here (and I believe that's good). On the other hand, if we never add any other library than OpenSSL then it's just complexity without benefit. As mentioned elsewhere in the thread, the current v23 patchset has the --with-ssl change as a separate commit to at least make it visual what it looks like. The documentation changes are in the main NSS patch though since documenting --with-ssl when there is only one possible value didn't seem to be helpful to users whom are fully expected to use --with-openssl still. -- Daniel Gustafsson https://vmware.com/
Commits
-
Add tab-completion for CREATE FOREIGN TABLE.
- 74527c3e022d 15.0 cited
-
Add tap tests for the schema publications.
- 6b0f6f79eef2 15.0 cited
-
Move Perl test modules to a better namespace
- b3b4d8e68ae8 15.0 cited
-
Adjust configure to insist on Perl version >= 5.8.3.
- 92e6a98c3636 15.0 cited
-
Simplify code related to compilation of SSL and OpenSSL
- 092b785fad3d 14.0 landed
-
Introduce --with-ssl={openssl} as a configure option
- fe61df7f82aa 14.0 landed
-
Implement support for bulk inserts in postgres_fdw
- b663a4136331 14.0 cited
-
Fix redundant error messages in client tools
- 6be725e70161 14.0 cited
-
doc: Apply more consistently <productname> markup for OpenSSL
- 089da3c4778f 14.0 landed
-
Check ssl_in_use flag when reporting statistics
- 6a5c750f3f72 14.0 cited