Re: WIP: Secure Transport support as OpenSSL alternative on macOS - Mailing list pgsql-hackers

From Daniel Gustafsson
Subject Re: WIP: Secure Transport support as OpenSSL alternative on macOS
Date
Msg-id FDD01C06-A62B-42C7-96EF-3DA7CF7D72AA@yesql.se
Whole thread Raw
In response to Re: WIP: Secure Transport support as OpenSSL alternative on macOS  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
> On 05 Oct 2016, at 16:45, Stephen Frost <sfrost@snowman.net> wrote:
>
> Daniel,
>
> * Daniel Gustafsson (daniel@yesql.se) wrote:
>> The main questions raised here are: is it of interest to support multiple SSL
>> libraries given the additional support burden and; is supporting Secure
>> Transport of any interest or is it a wasted effort to continue towards a full
>> frontend/backend/doc submission?
>
> We've already started working towards being able to support multiple
> libraries (in particular, Heikki's work to try and contain the OpenSSL
> bits) and I've been looking at what it'll take to add NSS support.

Building on his work it’s quite simple to keep this code contained to its own
files which is great.

> Generally speaking, I think we'd be better off looking at adding support
> for multi-platform libraries like NSS rather than OS-specific APIs, but
> I do understand how there can be advantages to using the OS API
> (keychain integration is certainly a big part of that, as you mention;
> the same is true for our Kerberos/GSS support).

In general I agree with you, supporting OS specific APIs on common platforms
(for some value of) which doesn’t ship with a useable OpenSSL installation can
still be of value I think.

>> On top of the OpenSSL situation in macOS, supporting Secure Transport makes
>> sense if the Keychain can be fully leveraged since that would allow IT
>> organisations to centrally manage and provision Mac clients without passing
>> certificate/key files around.  Should there be any interest in this I intend to
>> continue on one more library which is more geared towards server environments
>> like nss or <suggestions-welcome> once Secure Transport is done (scratching
>> another itch).
>
> I'd certainly be more than happy to help with the NSS side of things,
> though I'd want to have both client and server support for it.

I think any library supported should be required to have both client and server
support.  I stopped short after the frontend in this patch to get feedback but
will absolutely implement the backend as well.

NSS is on my list and I intend to get started on that somewhat shortly.

>> The attached show-and-tell patches are:
>
> Haven't actually looked at the patches yet, but very happy that you're
> also interested in this. :)
>
>>  0003.  A first little stab at tweaking the docs to mention support for
>>  multiple SSL libraries.  There is a lot left here but the idea is to contain
>>  the library specifics in subsections with the main sections being generic
>>  SSL support information.  On top of tweaking the existing sections I intend
>>  (once done) to write up the steps needed to implement support for an SSL
>>  library, this should perhaps be a README in the tree though?
>
> Agreed, this would be better as a README rather than in the formal docs,
> since adding support for another SSL library isn't really user-facing.

cheers ./daniel




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: improving on pgrminclude / pgcompinclude ?
Next
From: Fabien COELHO
Date:
Subject: Re: pgbench more operators & functions