On Mon, Aug 21, 2017 at 9:46 AM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Mon, Aug 21, 2017 at 6:21 AM, Daniel Gustafsson <daniel@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-8489B3B67556@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
