> On 05 Mar 2018, at 02:41, Michael Paquier <michael@paquier.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
