Re: WIP: Secure Transport support as OpenSSL alternative on macOS

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: WIP: Secure Transport support as OpenSSL alternative on macOS
Date: 2016-10-05 16:47:53
Message-ID: FDD01C06-A62B-42C7-96EF-3DA7CF7D72AA@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 05 Oct 2016, at 16:45, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> Daniel,
>
> * Daniel Gustafsson (daniel(at)yesql(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fabien COELHO 2016-10-05 16:48:18 Re: pgbench more operators & functions
Previous Message Robert Haas 2016-10-05 16:37:00 Re: improving on pgrminclude / pgcompinclude ?