On Mon, Nov 20, 2017 at 9:42 AM, Tomas Vondra <tomas.von...@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