> On 6 Mar 2018, at 22:08, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
>> On 3/4/18 17:15, Daniel Gustafsson wrote:
>>> 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.
>
>> I think it would be best if both this patch and the GnuTLS patch are
>> moved to the next CF and are attacked early in the PG12 cycle.
>
> +1. I think it's fairly important that those two get reviewed/committed
> in the same cycle, in case we need to adjust the relevant APIs. It
> seems unlikely that we can muster the effort to get both done for v11.
Attached is an updated patch for supporting the native macOS Secure Transport
library, rebased on top of current master. This patch still fails a couple of
the SSL tests, and doesn’t support any channel binding for SCRAM, but is IMO a
good enough WIP/snifftest to see if the current implementation approach is at
all any good and/or of interest.
Apart from being rebased on current master, this version contains mostly
general cleanups as well as removing support for anything older than High
Sierra (I no longer have access to systems on older versions so I’m unable to
test). On top of that, the few notable new things are:
* adds support for disallowing usage of the default user Keychain
* adds support for ssl_passphrase_command which was added in 8a3d9425290ff5f64
* extends the SSL tests to pass in separate expected output per backend. How
to refactor the test code to cope with multiple backends hasn’t really been
discussed, with the GnuTLS patch taking another approach, but this was handy
for me while testing to keep the capabilities and functionality separate.
(Reordering the parameters to test_connect_fails() was initially by mistake but
I like how it matches the order in test_connect_ok() so kept it). This should
probably be discussed on a separate thread though.
If there are parts which are insufficiently commented, let me know and I’ll do
my best to extend.
cheers ./daniel