Bug 237216 - net/freeradius3: fails to build with libressl
Summary: net/freeradius3: fails to build with libressl
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Ryan Steinmetz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-04-12 07:03 UTC by Felix Palmen
Modified: 2020-05-24 08:08 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (zi)


Attachments
build fixes for libressl (1.24 KB, patch)
2019-04-12 07:03 UTC, Felix Palmen
no flags Details | Diff
build fixes for libressl (2.73 KB, patch)
2019-05-19 08:22 UTC, Felix Palmen
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Felix Palmen 2019-04-12 07:03:35 UTC
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]
                        SSL_CTX_sess_set_get_cb(ctx, cbtls_get_session);       
                                                     ^~~~~~~~~~~~~~~~~         
/usr/local/include/openssl/ssl.h:730:20: note: passing argument to parameter 'ge
t_session_cb' here
    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]                 
                SSL_CTX_set_num_tickets(ctx, 1);                               
                ^
src/main/tls.c:3396:3: warning: implicit declaration of function 'SSL_CTX_set_num_tickets' is invalid in C99 [-Wimplicit-function-declaration]                 
                SSL_CTX_set_num_tickets(ctx, 0);                               
                ^
---

leading to this linker error:

---
LINK build/bin/radiusd
/usr/bin/ld: error: undefined symbol: SSL_CTX_set_num_tickets
>>> referenced by tls.c
>>>               build/objs/src/main/tls.o:(tls_init_ctx)
---

Suggest the attached patch to solve the issue.

BR, Felix
Comment 1 Ryan Steinmetz freebsd_committer freebsd_triage 2019-04-12 12:34:12 UTC
Please submit your patch upstream: https://github.com/FreeRADIUS/freeradius-server

When accepted, I'll merge to the port.
Comment 2 Felix Palmen 2019-04-12 16:06:49 UTC
Upstream issue is here:
https://github.com/FreeRADIUS/freeradius-server/issues/2611
Comment 3 Ryan Steinmetz freebsd_committer freebsd_triage 2019-04-12 23:03:51 UTC
Unless I'm missing something, the PR mentions issues with the patch that's there and it has yet to be accepted.  Please advise.
Comment 4 Felix Palmen 2019-04-13 08:43:45 UTC
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...

BR, Felix
Comment 5 Alan DeKok 2019-04-13 09:05:28 UTC
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.
Comment 6 Felix Palmen 2019-04-13 13:33:13 UTC
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.

BR, Felix
Comment 7 Felix Palmen 2019-05-19 08:22:53 UTC
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.
Comment 8 Felix Palmen 2020-05-24 08:08:06 UTC
This doesn't apply any more and the current version of freeradius builds fine with libressl.