Re: Support for NSS as a libpq TLS backend

Поиск
Список
Период
Сортировка
От Jacob Champion
Тема Re: Support for NSS as a libpq TLS backend
Дата
Msg-id a1798e46d6d801344ebc93672c6947ef5297c8a0.camel@vmware.com
обсуждение исходный текст
Ответ на Re: Support for NSS as a libpq TLS backend  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: Support for NSS as a libpq TLS backend  (Michael Paquier <michael@paquier.xyz>)
Список 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 по дате отправления:

Предыдущее
От: "alvherre@alvh.no-ip.org"
Дата:
Сообщение: Re: archive status ".ready" files may be created too early
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: PG14: Avoid checking output-buffer-length for every encoded byte during pg_hex_encode