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
|
Список | 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 по дате отправления: