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

From Michael Paquier
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id YAUz/A+KCCzjrvTr@paquier.xyz
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  (Daniel Gustafsson <daniel@yesql.se>)
List pgsql-hackers
On Tue, Nov 17, 2020 at 04:00:53PM +0100, Daniel Gustafsson wrote:
> Nice, thanks for the fix!  I've incorporated your patch into the attached v20
> which also fixes client side error reporting to be more readable.  The SCRAM
> tests are now also hooked up, albeit with SKIP blocks for NSS, so they can
> start getting fixed.

On top of the set of TODO items mentioned in the logs of the patches,
this patch set needs a rebase because it does not apply.  In order to
move on with this set, I would suggest to extract some parts of the
patch set independently of the others and have two buildfarm members
for the MSVC and non-MSVC cases to stress the parts that can be
committed.  Just seeing the size, we could move on with:
- The ./configure set, with the change to introduce --with-ssl=openssl.
- 0004 for strong randoms.
- Support for cryptohashes.

+/*
+ * BITS_PER_BYTE is also defined in the NSPR header files, so we need to undef
+ * our version to avoid compiler warnings on redefinition.
+ */
+#define pg_BITS_PER_BYTE BITS_PER_BYTE
+#undef BITS_PER_BYTE
This could be done separately.

src/sgml/libpq.sgml needs to document PQdefaultSSLKeyPassHook_nss, no?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: Wrong usage of RelationNeedsWAL
Next
From: Tatsuro Yamada
Date:
Subject: Re: list of extended statistics on psql