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