On Mon, Nov 20, 2017 at 9:42 AM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> I don't want to be the annoying guy, but this patch no longer applies
> due to 642bafa0c5f9f08d106a14f31429e0e0c718b603 touching the tests :-(
Sorry about that. Something more specific needs to happen here as well
for channel binding support with SCRAM. CheckSCRAMAuth() now assumes
that the channel binding mechanism SCRAM-SHA-256-PLUS can be published
to the client if SSL is used, because OpenSSL is the only
implementation available. Does gnutls include an API to allow an
application to fetch the bytes from the TLS finished message? I can
see some references by glancing at the tarball of gnutls 3.6.1, but
you would need something similar to OpenSSL's SSL_get_peer_finished().
If that cannot be achieved I think that it will be necessary to tweak
auth.c to not publish the -PLUS mechanism if for example the result of
be_tls_get_peer_finished() is NULL. No need for a new SSL-specific
API. At the end it would prove to be more portable to do so for all
the SSL implementations, MacOS stuff does not document an API to get
the TLS finish message bytes.
> If I get it right we ignore gnutls and use openssl (as it's the first
> checked in #ifdefs). Shouldn't we enforce in configure that only one TLS
> implementation is enabled? Either by some elaborate check, or by
> switching to something like
>
> --with-ssl=(openssl|gnutls)
WIth potential patches coming to use macos' SSL implementation or
Windows channel, there should really be only one implementation
available at compile time. That's more simple as a first step as well.
So +1 for the --with-ssl switch.
--
Michael