Re: Support for NSS as a libpq TLS backend - Mailing list pgsql-hackers

From Jacob Champion
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id a1798e46d6d801344ebc93672c6947ef5297c8a0.camel@vmware.com
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Support for NSS as a libpq TLS backend  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Tue, 2021-08-10 at 19:22 +0200, Daniel Gustafsson wrote:
> Another rebase to work around the recent changes in the ssl Makefile.

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.

You'd mentioned that perhaps we should support a call like

    PQsslAttribute(NULL, "library"); /* returns "NSS", "OpenSSL", or NULL */

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?

We could also add a new API (say, PQsslLibrary()) but I don't know if
that gives us anything in practice. Thoughts?

--Jacob

pgsql-hackers by date:

Previous
From: "alvherre@alvh.no-ip.org"
Date:
Subject: Re: archive status ".ready" files may be created too early
Next
From: Michael Paquier
Date:
Subject: Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode