Created attachment 203609 [details]
build fixes for libressl
Building with libressl gives the following compiler warnings:
src/main/tls.c:3286:33: warning: incompatible pointer types passing 'SSL_SESSION
*(SSL *, unsigned char *, int, int *)' (aka 'struct ssl_session_st *(struct ssl
_st *, unsigned char *, int, int *)') to parameter of type 'SSL_SESSION *(*)(str
uct ssl_st *, const unsigned char *, int, int *)' (aka 'struct ssl_session_st *(
*)(struct ssl_st *, const unsigned char *, int, int *)') [-Wincompatible-pointer-types]
/usr/local/include/openssl/ssl.h:730:20: note: passing argument to parameter 'ge
SSL_SESSION *(*get_session_cb)(struct ssl_st *ssl,
src/main/tls.c:3383:3: warning: implicit declaration of function 'SSL_CTX_set_num_tickets' is invalid in C99 [-Wimplicit-function-declaration]
src/main/tls.c:3396:3: warning: implicit declaration of function 'SSL_CTX_set_num_tickets' is invalid in C99 [-Wimplicit-function-declaration]
leading to this linker error:
/usr/bin/ld: error: undefined symbol: SSL_CTX_set_num_tickets
>>> referenced by tls.c
Suggest the attached patch to solve the issue.
Please submit your patch upstream: https://github.com/FreeRADIUS/freeradius-server
When accepted, I'll merge to the port.
Upstream issue is here:
Unless I'm missing something, the PR mentions issues with the patch that's there and it has yet to be accepted. Please advise.
Please see the linked commit over there, looks like they took the opportunity to get rid of all other libressl checks in their master branch. They want checks for specific libressl versions, which isn't always possible and definitely is an even worse maintenance nightmare. I don't see anything I can do from here on, sorry about that...
Please be aware that the MASTER branch is not the same as the v3.0.x branch.
The v3.0.x branch is for the version 3 releases, as may be obvious. The master branch is for ongoing new development, for what will be v4.
The short answer here is that we have to maintain FreeRADIUS for multiple platforms. If the libressl people cannot provide ways for us to tell what functionality exists in it, then it's impossible for us to know what functionality exists in it.
If the link between libressl and functionality is only known by a particular operating system, then the patches to make libressl work for that operating system belong in patches for that operating system.
We will not be butchering FreeRADIUS to work for *one* operating system, and *one* SSL library at the expense of all others.
We make every effort to be compatible across multiple operating systems and libraries. We try to work around version / functionality issues where we can.
But if we can't, then we can't. Blaming us for "dropping libressl support" is entirely inappropriate, and shows a poor understanding of the root problem.
The attached patch is very simple, adding a conditional in two places where openssl 1.1.1 APIs not supported by any version of libressl are used, and removing such a conditional in a place where current stable libressl correctly works using just the checks for the openssl API version. Couldn't be much simpler.
There's no other way right now than excluding libressl entirely for openssl 1.1.1 APIs as noone knows if/when these will be supported by libressl.
As for the other place that removes such a simple check, you COULD go to great lengths and identify the exact versions of libressl that need to be excluded *although* claiming openssl 1.1.0 API conformance -- or you could just be fine with "current stable works as expected", like this patch does.
So, I'm out of here -- solved the problem for me with a simple patch, that's good enough then.
Created attachment 204464 [details]
build fixes for libressl
With the latest stable libressl (2.9.1, first stable of 2.9), another special-case check for libressl has to go -- updated patch.