Summary: | net/freeradius3: fails to build with libressl | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | Ports & Packages | Reporter: | Felix Palmen <zirias> | ||||||
Component: | Individual Port(s) | Assignee: | Ryan Steinmetz <zi> | ||||||
Status: | Closed Overcome By Events | ||||||||
Severity: | Affects Only Me | CC: | aland, hostmaster+freebsd | ||||||
Priority: | --- | Flags: | bugzilla:
maintainer-feedback?
(zi) |
||||||
Version: | Latest | ||||||||
Hardware: | Any | ||||||||
OS: | Any | ||||||||
Attachments: |
|
Description
Felix Palmen
2019-04-12 07:03:35 UTC
Please submit your patch upstream: https://github.com/FreeRADIUS/freeradius-server When accepted, I'll merge to the port. Upstream issue is here: https://github.com/FreeRADIUS/freeradius-server/issues/2611 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... BR, Felix 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. BR, Felix 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.
This doesn't apply any more and the current version of freeradius builds fine with libressl. |