Hey Ted,
I should have been more clear in my previous email, but would it be
possible
to also revert OPENSSL_VERSION_NUMBER back to 0x1000107fL (or
0x1000108fL)?
This way LibreSSL would work as a drop-in replacement without
applications
needing to add explicit support for LibreSSL.
Ideas are still bouncing around, but basically OpenSSL fucked up from
the start.
Have you guys decided on anything or are you still bouncing ideas?
I see that 2.0.1 still ships with:
#define LIBRESSL_VERSION_NUMBER 0x20000000L
#define OPENSSL_VERSION_NUMBER 0x20000000L
Or to rephrase my question, is this going to stay like that and should 3rd
party applications start adding "&& !defined LIBRESSL_VERSION_NUMBER" in
order to compile with LibreSSL?
Instead of defining (e.g.) OPENSSL_HAS_ECDH, new versions
which are compiled without it define OPENSSL_NO_ECDH and then your
application code checks ifndef OPENSSL_NO_ECDH. But that test also
passes on older versions that lack the feature entirely, and then the
guarded code won't compile.
That's true, they've dropped the ball on that.
Testing for ifdef OPENSSL_FEATURE would work with both old libraries
that don't know about the feature and new libraries that don't support
it. As expected, OPENSSL does the opposite and makes life harder for
everyone.
To be fair, most of the popular functions from OpenSSL (SSL_CTX_{set,get},
etc) can be tested like that, thanks to the way control functions are
implemented (but not everyone is using this in order to determine
availability of the features). What they broke is that the defines aren't
guarded with #ifndef OPENSSL_NO_ECDH, etc. in the headers, so sometimes you
need more #ifdefs in order to make it work with library build with "no-xxx".
However, some functions aren't really "features", for example
X509_check_host() from OpenSSL-1.0.2, and OPENSSL_VERSION_NUMBER check is
the only reliable way to test for it... That is, unless you're compiling
against LibreSSL :(
Best regards,
Piotr Sikora
