> On Dec 10, 2014, at 10:58 AM, Lukas Tribus <luky...@hotmail.com> wrote: > >>> 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).
Sorry if this is long-winded: It is intentional - IIRC we discussed it during 2.0.1 - all 2.0.x releases said ‘2.0’ as well. One reason is that incrementing for sub-minor versions in the CVS source doesn’t mean anything, since the portable release schedule is independent in OpenBSD land. A second reason is to prevent software from using the version number or string to test for features, which has been frequently misused and abused. The presence of a string or version number in a header or program is mostly random. A third reason is, its redundant. How do you check what versions you are using of all other packages that don’t ship with headers or have version flags? Everything would be different. Luckily, there is a method that works for all software: your OS’s package manager! (you are using packages for production, right? not ‘make install’ into /usr/local on servers?) ‘<insert fave pkg manager query cmd> libressl’ Or, failing that, try pkg-config: pkg-config —modversion openssl pkg-config —modversion libtls pkg-config —modversion libssl pkg-config —modversion libcrypto Note that each of these is actually individually versioned, and the version increments as the API and ABI changes for each library (though libtls may get a pass for a little while longer - buyer beware) Though I’m not 100% opposed to some sort of post-processing addition to the portable tree that could fiddle with that overarching version string as it is embedded into openssl(1), it’s really not a good thing to rely on. Especially since more general solutions already exist. > > > Regards, > > Lukas > > >
