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

From Daniel Gustafsson
Subject Re: Support for NSS as a libpq TLS backend
Date
Msg-id 6C7A2D6A-3D05-4C3B-B1DA-C96E97F31AC6@yesql.se
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Support for NSS as a libpq TLS backend
List pgsql-hackers
> On 9 Feb 2021, at 07:47, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Feb 09, 2021 at 12:08:37AM +0100, Daniel Gustafsson wrote:
>> Attached is a new patchset where I've tried to split the patches even further
>> to try and separate out changes for easier review.  While not a perfect split
>> I'm sure, and clearly only for review purposes, I do hope it helps a little.
>> There is one hunk in 0002 which moves some OpenSSL specific code from
>> underneath USE_SSL, but thats about the only non-NSS change left in this
>> patchset AFAICS.
>
> I would have imagined 0010 to be either a 0001 or a 0002 :)

Well, 0010 is a 2 in binary =) Jokes aside, I just didn't want to have a patch
referencing files added by later patches in the series.

>     errmsg("hostssl record cannot match because SSL is not supported by this build"),
> -    errhint("Compile with --with-ssl=openssl to use SSL connections."),
> +    errhint("Compile with --with-ssl to use SSL connections."),
> Actually, we could change that directly on HEAD as you suggest.  This
> code area is surrounded with USE_SSL so there is no need to mention
> openssl at all.

We could, the only reason it says =openssl today is that it's the only possible
value but thats an implementation detail.  Changing it now before it's shipped
anywhere means the translation will be stable even if another library is
supported.

> 0002 could just be committed as-is.

It can be, it's not the most pressing patch scope reduction but everything
helps of course.

> I am also looking at 0003 a bit.

Thanks.  That patch is slightly more interesting in terms of reducing scope
here, but I also think it makes the test code a bit easier to digest when
certificate management is abstracted into the API rather than the job of the
testfile to perform.

--
Daniel Gustafsson        https://vmware.com/


pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: adding wait_start column to pg_locks
Next
From: Amit Kapila
Date:
Subject: Re: Single transaction in the tablesync worker?