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

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
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 01:41:01
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Sun, Mar 04, 2018 at 11:15:58PM +0100, Daniel Gustafsson wrote:
> Commitfest Status
> =================
> Do I think this patch is realistic to target for v11? Well. Given where we
> are in the cycle, I don’t think any new TLS implementation going in is
> realistic at this point since none of the proposed ones have had enough tyre
> kicking done. That might change should there be lots of interest and work
> started soon, but as has been discussed elsewhere recently the project has
> limited resources. I have time to work on this, and support reviewers of it,
> but that’s only piece of the puzzle.

This patch has been around for some time now, and a couple of people
have expressed interest in the feature, so it seems to me that there is
still some room to get new features in the tree. I am not personally
planning to spend much time on reviewing this specific implementation
though, however...

> 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!

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:

> 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. Seeing the GUC portion changed. Even if this is not
changed, there is always the point of assuming that the existing
SSL parameters map to OpenSSL, and add on top of it the new sets. But
that would be confusing for the user than renaming simply the existing

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-03-05 01:53:58 Re: Server won't start with fallback setting by initdb.
Previous Message Masahiko Sawada 2018-03-05 01:25:30 Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently