Created attachment 164463 [details] Patch net/freeradius3/Makefile to fix/improve kerberos selection. Hi net/freeradius3 seems to link always against Heimdal kerberos in base as soon as one of the 3 possible options is enabled. The issue is already visible 'make stage': # HEIMDAL # ldd work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so: libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x801604000) -> OK. HEIMDAL_PORT: Builds but doesn't find the library and thus no rlm_krb5.so is built KERBEROS: stops with an error when building rlm_krb5, I haven't dug deeper there. The main cause is due to an upstream change which changed the Kerberos parameters starting with 3.0.1. 3.0.0 used the same options as are still valid with 2.2.9, not 3.0.1 onwards.* The relevant file in the FreeRADIUS source is src/modules/rlm_krb5/configure(.ac), the option is not revealed by 'configure --help' I'd propose to make a selection group which makes it impossible to chose more than 1 Kerberos implementation, but still allows disabling rlm_krb5 entirely. The dependency was changed with the following idea: HEIMDAL_BASE: libkrb5.so*.26*, otherwise the dependency is fullfilled by librkrb5.so in base After the modifications: # HEIMDAL (test with and without security/heimdal installed) # ldd work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so: libkrb5.so.11 => /usr/lib/libkrb5.so.11 (0x801604000) [...] # HEIMDAL_PORT (security/heimdal installed, security/krb5 absend as they conflict) # ldd work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so: libkrb5.so.26 => /usr/local/lib/heimdal/libkrb5.so.26 (0x801604000) [...] # KERBEROS (security/krb5 instaled, security/heimdal absend as they conflict) # ldd work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so work/stage/usr/local/lib/freeradius-3.0.10/rlm_krb5.so: libkrb5.so.3.3 => /usr/local/lib/libkrb5.so.3.3 (0x801604000) [...] There is still 1 corner case which I don't know how to fix yet: If the system has krb5 installed from ports/packages but the port is built with HEIMDAL from base it gets confused and fails to build. Upstream has said that usually there should not be 2 different Kerberos libraries and currently I don't know where the exception should be handled best. -- Mathieu * Here is the commit from back then: https://github.com/FreeRADIUS/freeradius-server/commit/7889d4b840920526b4598422771617d389ea5ab7
Created attachment 165747 [details] net/freeradius3/Makefile: Fix/improve kerberos selection. Hi This updated patch prevents building if rlm_krb5 is enabled to build against Heimdal in base when security/krb5 is present. It's not the best solution, but it prevents breaking builds. I haven't found a way to isolate with the new kind of option introduced back in 3.0.1. It also now removes the switches gone with as 3.0.1 they don't have any effect on configure behaviour. I tried to figure out a way with upstream how to prevent this, but they mostly expect one kerberos implementation to be present during build and trying to point it more closely to the libraries in base didn't succeed. See discussion on Github: https://github.com/FreeRADIUS/freeradius-server/issues/1466 -- Mathieu
Hi Is there something I can or need get done first? The issue applies to 3.0.11 too and since the port hasn't much changed between 3.0.10 and now, the patch should still apply pretty much. Looking forward to an update Mathieu
Can you include poudriere runs for the 3 cases?
Created attachment 166500 [details] poudriere testport: HEIMDAL in base
Created attachment 166501 [details] poudriere testport: HEIMDAL from ports
Created attachment 166502 [details] poudriere testport: MIT from ports Hi Ryan OK, that's the last one, all built in 10.2 amd64 jails. If that works, enabling the Heimdal in base as default would be simple IMHO, as it doesn't introduce any additional dependency. If you'd like to see more, feel free, I'll try to get it. -- Mathieu
Additional commits have resolved this issue.
How can you tell that it links properly when it doesn't even compile properly? https://lists.freebsd.org/pipermail/freebsd-ports/2017-November/110997.html
Unless I am mistaken, you are still using an old version of the ports tree. The URL you cited indicates you are using 3.0.15_1 of the port. The fixes for the Kerberos stuff are in 3.0.15_2. Please verify your local versions against what's on one of the following URLs and retry your build. https://www.freshports.org/net/freeradius3 https://svnweb.freebsd.org/ports/head/net/freeradius3/ Thank you for your courteous and prompt replies, -r
The changes in ports r454056 enable a successful build with the (new) MITKRB_PORT option. Some feedback: 1. "Additional commits have resolved this issue." is vague. It would have been more helpful to say something like, "The changes in commits <x> and <y> resolve this issue." Bonus points for remarks on why you didn't accept the submitter's patch, or, if it was the basis of your own patches, to give the submitter credit for the applicable hunks or inspiration. 2. If I hadn't come back to look at this bug---which I did because I was going to try to validate and refresh the proposed patch---I might have been waiting for a follow-up on our freebsd-ports@ thread for a long time. Without a response on the thread, I and other current or future observers would have no reason to expect the status of this bug had changed. Clearly, I could have added myself to the CC list. What would have benefited a larger group, though, is if you had closed the loop on the list to point to the resolution. It would have been better to respond to the thread to mention what you had done, or at least to reference a change of state in another venue. 3. Changing OPTION names when the semantics do not change is a POLA violation. Failing to mention it in the commit message, never mind UPDATING or the comments of this bug compounds that problem. I got pretty far down the path of rebuilding and testing the updated port before I realized that the KERBEROS OPTION was no longer meaningful. It would have been better to fix the function of the applicable OPTION(s) without changing the name(s). If you wanted to change the name anyway, it would have been better to call out the change in the commit message. It would have been even better if you had changed the names to align to prior art elsewhere in the ports tree, like dns/bind10 and mail/dovecot, which recognize GSSAPI_{NONE,BASE,HEIMDAL,MIT} following Mk/Uses/gssapi.mk, even if this isn't exactly a case of GSSAPI. I would be glad to continue this dialog offline if you like.