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 87A43C79-A8FF-4C06-A3BF-288869E4AC02@yesql.se
Whole thread Raw
In response to Re: Support for NSS as a libpq TLS backend  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Support for NSS as a libpq TLS backend  (Stephen Frost <sfrost@snowman.net>)
Re: Support for NSS as a libpq TLS backend  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
> On 3 Feb 2022, at 15:07, Peter Eisentraut <peter.eisentraut@enterprisedb.com> wrote:
>
> On 28.01.22 15:30, Robert Haas wrote:
>> I would really, really like to have an alternative to OpenSSL for PG.
>
> What are the reasons people want that?  With OpenSSL 3, the main reasons -- license and FIPS support -- have gone
away.

At least it will go away when OpenSSL 3 is FIPS certified, which is yet to
happen (submitted, not processed).

I see quite a few valid reasons to want an alternative, a few off the top of my
head include:

- Using trust stores like Keychain on macOS with Secure Transport.  There is
AFAIK something similar on Windows and NSS has it's certificate databases.
Especially on client side libpq it would be quite nice to integrate with where
certificates already are rather than rely on files on disks.

- Not having to install OpenSSL, Schannel and Secure Transport would make life
easier for packagers.

- Simply having an alternative.  The OpenSSL projects recent venture into
writing transport protocols have made a lot of people worried over their
bandwidth for fixing and supporting core features.

Just my $0.02, everyones mileage varies on these.

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




pgsql-hackers by date:

Previous
From: Dag Lem
Date:
Subject: Re: daitch_mokotoff module
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: row filtering for logical replication