On Mon, Aug 21, 2017 at 9:46 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Mon, Aug 21, 2017 at 6:21 AM, Daniel Gustafsson <dan...@yesql.se> wrote: >> I think the intended use case of the GUC should drive the decision on >> fallback. >> If the GUC isn’t supposed to be a way to figure out if the server was built >> with SSL support, then not existing in non-SSL backends is fine. If, >> however, >> we want to allow using the GUC to see if the server has SSL support, then >> there >> needs to be a “None” or similar value for that case. > > Only GUCs related to debugging have their existence defined based on a > #define, so it seems to me that if Postgres is compiled without any > SSL support, this parameter should still be visible, but set to > "none".
The last set of patches available here does not apply: https://www.postgresql.org/message-id/b5e2b87d-3e8a-4597-9a7f-8489b3b67...@yesql.se The SSL test refactoring is one cause. I think as well that this is crashing when attempting to use SCRAM authentication with the SSL brand of macos and SCRAM's channel binding. I am going to send a patch which allows handling of no support for channel bindings for a given SSL implementation, something needed as well by the gnutls patch. Please make sure that you define at least be_tls_get_peer_finished() and pgtls_get_finished() with a NULL result and a length of 0 as return results as, as far as I can see, macos does not give direct access to the TLS finish message bytes. At least that's not documented. -- Michael
