>> I believe a not to be underestimated amount of applications #ifdef's
>> certain functionality of openssl out, for example NPN
>> (SSL_CTRL_SET_TLSEXT_HOSTNAME) or server preferential cipher ordering
>> (SSL_OP_CIPHER_SERVER_PREFERENCE).
>
> That's rather different to checking using defines with TLSEXT_TYPE_* - these
> are just definitions of TLS extension types and assuming that the presence of
> these implies support is plain crazy.
Well, its what multiple programs came up with in absence of advanced autoconf
function tests. I agree that this sucks; but other than implementing autoconf
there doesn't seem to be an easy way out currently.
> As has been documented elsewhere, the feature negation approach is seriously
> broken - presumably we should have defined OPENSSL_NO_ALPN to indicate that
> we did not have ALPN support, but you then have a race between knowing what
> you need to indicate a lack of support for and actually saying you do not
> support it. On the other hand defining OPENSSL_ALPN as a feature would have
> allowed software to check for that instead of trying to do half baked checks
> based on things like TLS extension types that do not imply an API exists.
Acked.
> It has just been committed so hopefully one less problem to deal with (or I
> just created another one, depending on how you look at it :)
Thanks!
On other thing: OPENSSL_VERSION_TEXT (src/crypto/opensslv.h) is currently set
to "LibreSSL 2.1". Seems like this was done after the 2.1.0 release (cvs log):
> "This makes 'openssl version' print a string that matches the -portable
> release number."
Is the intention to keep this as-is, or is this simply an oversight? The are
a lot of changes within 2.1 (including security fixes), I think its important
to show the exact release. "openssl version" is not the only user; haproxy for
example shows this in the version output (haproxy -vv).
Regards,
Lukas
