Re: LibreSSL 2.1.2 linking issues
>> Many Lolz.. Lukas you just made my day.. >> >> They've been misused that way, and more than once, by more than one >> project. This is why we really want it to be just a string, and >> strongly discourage people from using it in the way it has been >> abused. >> >> ... we could always change it so the string is wheezy, dopy, sneezy, >> drippy, or whatever for each release ;) > > Lukaz, is this the world you want: > > /* The following test is suggested by Richard Levitte */ > if (((OPENSSL_VERSION_NUMBER ^ SSLeay()) & 0xff0f) > > Yes, it is. Because you are asking for it. I don't think it is. I'm perfectly fine with freezing OPENSSL_VERSION_NUMBER and LIBRESSL_VERSION_NUMBER forever and ever. I asked to bump the string in OPENSSL_VERSION_TEXT, which is currently set to "LibreSSL 2.1", but apparently that is just as bad. Of that I was not aware. Well then, let me ask you this: Why not drop the version in OPENSSL_VERSION_TEXT altogether and simply set it to "LibreSSL"? That way there is no confusion about what to expect from its content while still permitting applications accessing it to build. FYI: boringssl dropped this symbol completely, which means it breaks the build of applications accessing it. That I believe is too intrusive in the LibreSSL case. It looks like serious packaging (of portable) should explicitly look at major/minor in ssl/shlib_version then, instead of the actual libressl release, just as its done in ports (afaik). Lukas
Re: LibreSSL 2.1.2 linking issues
> Sorry if this is long-winded: Dito :) > 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. Agreed that this doesn't make much sense for CVS source, for the -portable tarballs however it would. > 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. Have strings really been misused this way? Yikes... > 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?) I get your point, but I don't believe its always that simple. Should we really exclusively care about users of the packaging systems provided by the OS, nobody else? Enterprise users may do their own packaging (of specific application using libssl), commercial software may comes as a binary package, both linked against shared libssl. The embedded sector may has similar use cases. Having no idea what libssl/lilbcrypto release the application was build against is not very pleasant when you have to troubleshoot strange problems or crahes and in the end the simple reason is that there is no ABI or even API compatibility between the library the application was build against and the library that is actually running. This is why haproxy -vv shows both build and runtime release [1]. Not to affect code paths (at least in this instance), but to inform. > incrementing for sub-minor versions While we are talking "sub-minor" on the portable site, in cvs we are talking "major" [2,3], so perhaps we are looking at this from the wrong angle: should we really only increment the portable releases on a sub-minor level given the actual ABI/API changes across those releases? Will the portable tree or libressl in general ever get any ABI/API stability, or is it simply to soon to talk about those things and we should let it settle some more? > 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) I agree, that would work. Regards, Lukas [1] http://www.haproxy.org/git?p=haproxy.git;a=commitdiff;h=0cff0dbfc0813d01a0ebbd3910519bfac4d9eec2 [2] https://github.com/libressl-portable/openbsd/commit/c8d18f00f5cf5881d979b0ecbdf0ae73f8184865 [3] https://github.com/libressl-portable/openbsd/commit/52a59f2208d380d4c49c4c3d6866766bad13f4b4
Re: LibreSSL 2.1.2 linking issues
>> 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
Re: LibreSSL 2.1.2 linking issues
> 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). In fact if I'm not mistaken that is exactly the reason why both LibreSSL [1] and BoringSSL [2] have "opensslfeatures.h". > But, I believe jsing@ has a patch in-review to merge the rest ALPN > support any way. Great, thanks! [1] https://github.com/libressl-portable/openbsd/blob/master/src/lib/libssl/src/crypto/opensslfeatures.h [2] https://boringssl.googlesource.com/boringssl/+/987b8f1e715414b0b278a4a0c64ec9c97ad65f58%5E!/
LibreSSL 2.1.2 linking issues
Hi, I'm linking haproxy (current git master) against libressl 2.1.2 portable on linux, but seeing 2 issues (not present in previous libressl 2.1.1): Issue number one (not sure what happens here): include/openssl/ssl.h:503:2: error: unknown type name ‘uint8_t’ uint8_t *tlsext_ecpointformatlist; /* peer's list */ ^ include/openssl/ssl.h:505:2: error: unknown type name ‘uint16_t’ uint16_t *tlsext_ellipticcurvelist; /* peer's list */ ^ include/openssl/ssl.h:1146:2: error: unknown type name ‘uint8_t’ uint8_t *tlsext_ecpointformatlist; /* our list */ ^ include/openssl/ssl.h:1148:2: error: unknown type name ‘uint16_t’ uint16_t *tlsext_ellipticcurvelist; /* our list */ ^ Issue number two is quite clear: libressl 2.1.2 defines TLSEXT_TYPE_application_layer_protocol_negotiation but doesn't support ALPN, while in haproxy the ALPN callers are ifdef'ed around that symbol, which obviously fails: src/ssl_sock.c: In function ‘ssl_sock_prepare_ctx’: src/ssl_sock.c:1650:3: warning: implicit declaration of function ‘SSL_CTX_set_alpn_select_cb’ [-Wimplicit-function-declaration] SSL_CTX_set_alpn_select_cb(ctx, ssl_sock_advertise_alpn_protos, bind_conf); ^ src/ssl_sock.c: In function ‘smp_fetch_ssl_fc_alpn’: src/ssl_sock.c:3590:2: warning: implicit declaration of function ‘SSL_get0_alpn_selected’ [-Wimplicit-function-declaration] SSL_get0_alpn_selected(conn->xprt_ctx, ^ make: *** [src/ssl_sock.o] Error 1 I know nginx uses this symbol as-well to determine whether there is ALPN support. I don't think it makes much sense to define this symbol unless there is actually ALPN support in the code, does it? Any help with this is much appreciated. Regards, Lukas
