On Wed, 10 Dec 2014, Lukas Tribus wrote: > > On 2014/12/09 07:37, Brent Cook wrote: > >> If an app calls a function, it should probably check if that function > >> exists during configuration time, rather than inferring if define A > >> exists, function B and C must exist. Especially things that are just > >> protocol constant definitions. If they are using autoconf, a call to > >> AC_CHECK_FUNCS would be better, IMHO. > > > > Neither nginx nor haproxy use autoconf. nginx has it's own config > > testing infrastructure where this could be added, though they appear > > to be deliberately trying to keep the maze of #ifdef and configuration > > tests to a minimum. haproxy has a simple Makefile with USE_* flags > > set for different system types, it's quite clean and straightforward > > but doesn't allow for this type of test. > > Thats correct indeed. > > 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. For example, TLSEXT_TYPE_user_mapping is defined but AFAIK neither LibreSSL or OpenSSL have any support for it. The above mentioned defines are ones that exist as part of an API - if those exist then it is likely a fair assumption that the API exists and is useable. > In fact if I'm not mistaken that is exactly the reason why both > LibreSSL [1] and BoringSSL [2] have "opensslfeatures.h". 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. > > But, I believe jsing@ has a patch in-review to merge the rest ALPN > > support any way. 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 :) > Great, thanks! > > > > [1] > https://github.com/libressl-portable/openbsd/blob/master/src/lib/libssl/src >/crypto/opensslfeatures.h [2] > https://boringssl.googlesource.com/boringssl/+/987b8f1e715414b0b278a4a0c64e >c9c97ad65f58%5E!/ -- "Action without study is fatal. Study without action is futile." -- Mary Ritter Beard
