Hi Lukas,
On Wed, Nov 16, 2016 at 07:33:09PM +0100, Lukas Tribus wrote:
> Hello!
>
>
> Am 16.11.2016 um 15:39 schrieb Willy Tarreau:
> >
> > Same here. What is annoying is that every time it appears, it's protected
> > by a #if OPENSSL_VERSION_NUMBER >= 1.1.0 so that means that LibreSSL is
> > spoofing OpenSSL version numbers without providing compatibility. If so,
> > that will become quite painful to support.
>
> Something like this (which is already in the code twice) should permit the
> build:
> #if (OPENSSL_VERSION_NUMBER >= ......... && !defined
> LIBRESSL_VERSION_NUMBER)
>
> It will be a mess, and it will unconditionally disable new features for all
> LibreSSL releases, but I don't see any other easy way out of this.
I think for the mid-term what we can do is to check what highest openssl
version LibreSSL is compatible with, and redefine it accordingly. For example
(not correct values) :
#if LIBRESSL_VERSION_NUMBER >= 1.2.3.4
#undef OPENSSL_VERSION_NUMBER
#define OPENSSL_VERSION_NUMBER 1.0.2
#endif
For the long term we may do something better by having a list of features
and a compatibility matrix, like this :
#if LIBRESSL_VERSION_NUMBER >= 1.2.3.4 || OPENSSL_VERSION_NUMBER >= 1.0.2
#define SSL_HAVE_FEATURE_FOO
#endif
But that only works as long as we don't have too many of them, which I
think will continue to be valid for a long time as libressl's existence
is conditionned by a bit of compatibility.
> LibreSSL folks will insist on some autoconf testing of functions at build
> time, which is not something we can do in haproxy, so there will never be
> a good solution to this.
And this is broken by design because it means you have no way to correctly
check compatibility in your code.
> My suggestion for users would be to use stick to OpenSSL, even if LibreSSL
> is available.
That's what this report demonstrates unfortunately. Breaking an API while
claiming compatibility is not the smartest thing to do :-/
Willy
