Re: Supporting tls-server-end-point as SCRAM channel binding for OpenSSL 1.0.0 and 1.0.1

On Wed, Jun 06, 2018 at 12:37:00PM -0400, Alvaro Herrera wrote:
> On 2018-May-29, Michael Paquier wrote:
> If SCRAM channel binding is an important aspect to security, and the
> older OpenSSL versions will still be around in servers for some time
> yet, it seems like it behooves us to go the extra mile and provide an
> implementation that works with such existing servers. Looking at
> yum.postgresql.org, we seem to offer Postgres 11 packages for RHEL 6,
> which appears to have openssl 1.0.0.

Or 1.0.1 as Tom has mentioned.

> Anyway, even if I'm wrong, this thread has stalled. I hereby sprinkle
> this thread with magic RMT dust for it to get fixed soon.

I am still not completely sure what is the correct course of action
here. Heikki and Peter and not much in favor of adding more complexity
here as OpenSSL has a long history of having a non-linear history across
platforms. On the other side, PGDG provides packages down to RHEL6, and
there are surely servers which use it as backend.

I also had a look at how to report the version of OpenSSL when compiling
with MSVC or ./configure. For MSVC, it could be possible to do
something like the attached as openssl is a command available and
Windows installers of OpenSSL usually have the command. One potential
problem is that dll can be either installed in the generic Windows path
where all DLLs are or into the specific path defined at installation as
a choice. Hence this should be more defensive and only trigger if the
executable can be found. Please consider this as just a draft patch
(this generates a warning as well if OPENSSL_CONF is not defined).

For *nix platforms, we could have an m4 macro which calls
OpenSSL_version_num() to get the version number and then
OpenSSL_version(int t) which provides a nice version string. My m4-foo
is not that advanced, but that looks doable.
--
Michael