Re: Support for NSS as a libpq TLS backend

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Jacob Champion <pchampion(at)vmware(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "andrew(dot)dunstan(at)2ndquadrant(dot)com" <andrew(dot)dunstan(at)2ndquadrant(dot)com>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "thomas(dot)munro(at)gmail(dot)com" <thomas(dot)munro(at)gmail(dot)com>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>
Subject: Re: Support for NSS as a libpq TLS backend
Date: 2021-08-18 09:48:23
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 18 Aug 2021, at 02:32, Michael Paquier <michael(at)paquier(dot)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

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-08-18 10:01:43 Re: [bug] Logical Decoding of relation rewrite with toast does not reset toast_hash
Previous Message Daniel Gustafsson 2021-08-18 09:38:44 Small typo fix in logical decoding example