As noted in 77fb2321-9210-4ad4-b7fc-67623a583...@justatheory.com, OpenSSL is being somewhat dismantled on macOS starting with 10.11 El Capitan. To scratch my own itch I decided to take a stab at adding support for the Secure Transport library. The idea is to make it as much of a drop-in for the OpenSSL support as possible, supporting the same file formats etc (Secure Transport have PKCS12 API calls while support PEM requires using lower level APIs).
Only the frontend has been implemented so far. I used a vanilla OpenSSL- compiled backend for testing (see patch 0002 below). Currently the CRL tests fail since Secure Transport doesn’t handle manual CRL lists like OpenSSL, CRL handling is done automatically by the Keychain upon validation. One alternative for supporting this could perhaps be to create a temporary Keychain for the duration of the connection over which more control can be had (need to research this further). For now, no Secure Transport specifics are supported but the idea is to add support for loading certificates and keys from the Keychain as well as from the usual locations. The engine and compression settings will however be no-ops since there is no support in Secure Transport for these. Being an early WIP show-and-tell submissions and not something up for code review (anyone wanting to take a look is of course more than welcome), it is deliberately rough around the edges. Except the manual CRL loading, it’s mostly featurecomplete with the OpenSSL frontend, TODO items include: removing use of private and deprecated API calls; ensure release of all resources; support certificates/keys in Keychain; possibly use temporary keychains for connections; support passphrase entering (there has been lots of deprecations around that, need to figure out the supported way forward); tidy up, and write better, comments; documentation. 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? 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). The attached show-and-tell patches are: 0001. The WIP frontend support for Secure Transport together with minimal scaffolding around it such as Makefile and autoconf. 0002. Adding support to PostgresNode.pm to run the server binaries from a defined path making it easier to test a frontend without having to a) implement the backend at the same time or b) fiddle with paths manually. The SSL tests are the only ones modified. There is nothing Secure Transport specific in this patch so iff the approach is deemed interesting it could be considered out of band. Since the only consumer is testing SSL during development it might be too invasive however. 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? Thoughts, comments? cheers ./daniel
0001-WIP-Add-support-for-macOS-Secure-Transport-SSL-libra.patch
Description: Binary data
0002-Enable-ssl-tests-to-be-using-a-different-set-of-Post.patch
Description: Binary data
0003-A-first-stab-at-updating-the-docs-to-handle-multiple.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers