Horton

Re: Support for NSS as a libpq TLS backend

Daniel Gustafsson <daniel@yesql.se>

View thread View on postgr.es
From: Daniel Gustafsson <daniel@yesql.se>
To: Michael Paquier <michael@paquier.xyz>
Cc: 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>, "andres@anarazel.de" <andres@anarazel.de>, "thomas.munro@gmail.com" <thomas.munro@gmail.com>, "sfrost@snowman.net" <sfrost@snowman.net>
Date: 2021-08-18T09:48:23Z
Lists: pgsql-hackers 
> On 18 Aug 2021, at 02:32, Michael Paquier <michael@paquier.xyz> wrote:
> 
> On Wed, Aug 18, 2021 at 12:06:59AM +0000, Jacob Champion wrote:
>> I have a local test suite that I've been writing against libpq. With
>> the new ssldatabase connection option, one tricky aspect is figuring
>> out whether it's supported or not. It doesn't look like there's any way
>> to tell, from a client application, whether NSS or OpenSSL (or neither)
>> is in use.
> 
> That's about guessing which library libpq is compiled with, so yes
> that's a problem.
> 
>> so that you don't have to have an actual connection first in order to
>> figure out what connection options you need to supply. Clients that
>> support multiple libpq versions would need to know whether that call is
>> reliable (older versions of libpq will always return NULL, whether SSL
>> is compiled in or not), so maybe we could add a feature macro at the
>> same time?
> 
> Still, the problem is wider than that, no?  One cannot know either if
> a version of libpq is able to work with GSSAPI until they attempt a
> connection with gssencmode.  It seems to me that we should work on the
> larger picture here.

I think we should do both.  PQsslAttribute() already exists, and being able to
get the library attribute for NULL conn object when there are multiple
libraries makes a lot of sense to me.  That doesn’t exclude working on a better
way for apps to interrogate the libpq they have at hand for which capabilities
it has.  Personally I’m not sure what that API could look like, but we should
discuss that in a separate thread I guess.

--
Daniel Gustafsson		https://vmware.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