Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative
Date: 2018-03-05 11:25:36
Message-ID: E61DBB1A-E7EB-4FE1-9CB6-772AD4EA48D0@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 05 Mar 2018, at 02:41, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> On Sun, Mar 04, 2018 at 11:15:58PM +0100, Daniel Gustafsson wrote:

>> If no new TLS library is supported in v11, we still got cleaner SSL support out
>> of it due to the work performed to further remove our dependency on OpenSSL, so
>> we still come out on top IMO. Thanks Peter et.al!
>
> I am definitely interested in plugging in more generic APIs for this
> release, so as people can also fork Postgres and implement their own SSL
> implementation more easily. One patch that still applies in this area
> is I think this one to allow SSL implementations let the backend know
> more easily is channel binding needs to be implemented or not:
> https://commitfest.postgresql.org/17/1491/

Right. Regardless of the state of this patch I hope that can make it into 11
to further make 11 a good base for hacking on SSL code.

>> So, TL;DR: both frontend and backend API are implemented except for SCRAM
>> channel binding and CRL file support, it needs tests and documentation, it does
>> not implement pgcrypto, it will be fixed to support whichever GUC strategy the
>> project decides on for multiple TLS library support.
>
> One bit of conclusion in this area is that at Peter E has argued in
> favor of having separate configure switches for each each SSL
> implementation instead of reworking things into a single, generic
> switch. The GUC portion is also pointing in the direction of having one
> set of parameters per implementation so as assigning default values is a
> no-brainer.

FWIW I completely agree with this approach. With a single set of GUCs for all
implementations I fear that we risk ending up with configurations that require
shoehorning, and that will no-doubt open the risk for vulnerable servers due to
the configuration being hard to get right. Either approach does introduce a
problem for moving a hand-edited postgresql.conf files between clusters running
different libraries, but thats hard to avoid I think.

cheers ./daniel

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen Frost 2018-03-05 11:36:14 Re: [PATCH] Verify Checksums during Basebackups
Previous Message Pavan Deolasee 2018-03-05 11:02:42 Re: [HACKERS] MERGE SQL Statement for PG11