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 DDC8E390-1044-4693-AE34-81731B2291FA@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 10 Feb 2021, at 08:23, Michael Paquier <michael@paquier.xyz> wrote:
>
> On Tue, Feb 09, 2021 at 10:30:52AM +0100, Daniel Gustafsson wrote:
>> It can be, it's not the most pressing patch scope reduction but everything
>> helps of course.
>
> Okay.  I have spent some time on this one and finished it.

Thanks, I'll post a rebased version on top of this soon.

>> 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.
>
> That's my impression.  Still, I am wondering if there could be a
> different approach.  I need to think more about that first..

Another option could be to roll SSL config into PostgresNode and expose SSL
connections to every subsystem tested with TAP. Something like:

    $node = get_new_node(..);
    $node->setup_ssl(..);
    $node->set_certificate(..);

That is a fair bit more work though, but perhaps we could then easier find
(and/or prevent) bugs like the one fixed in a45bc8a4f6495072bc48ad40a5aa03.

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




pgsql-hackers by date:

Previous
From: Ranier Vilela
Date:
Subject: Re: pg_cryptohash_final possible out-of-bounds access (per Coverity)
Next
From: Etsuro Fujita
Date:
Subject: Re: Asynchronous Append on postgres_fdw nodes.