Anyone who's been following FreeRADIUS knows that v4 is the "always tomorrow" project. One of the reasons is that for a long time RadSec was "up and coming", but actual work on it was minimal. Unfortunately, other things were higher priority. Happily, it looks like that work is coming to a close. There have been substantial commits to v4 in the last week, which move the bar forward for RadSec. We don't (yet) have a functioning RadSec in the server, but for the first time in a long while, progress is being made. With luck, we will be releasing a beta of v4 before December, which includes RadSec. Alan DeKok.
Alan DeKok via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
With luck, we will be releasing a beta of v4 before December, which includes RadSec.
Fantastic! Our initial fiddling with v4 on a test server has been very promising. (RadSec not being a blocker for us, actually.) I was actually able to use the detach feature to pre-cache AD group and CPPM RBAC attribute lookups while TLS negotiation was still ongoing for a client. Should be a very welcome speed improvement and untangle a bit of unnecessary and cretinous proxy daisy chaining. We're looking forward to it very enthusiastically. Did get one segv, but only when the server was badly misconfigured.
On Sep 25, 2026, at 11:15 AM, Brian Julin <BJulin@clarku.edu> wrote:
Fantastic! Our initial fiddling with v4 on a test server has been very promising. (RadSec not being a blocker for us, actually.)
Yes, there are a lot of people who don't need RadSec. Or at least, don't need it immediately.
I was actually able to use the detach feature to pre-cache AD group and CPPM RBAC attribute lookups while TLS negotiation was still ongoing for a client. Should be a very welcome speed improvement and untangle a bit of unnecessary and cretinous proxy daisy chaining.
Nice! There are a _ton_ of new features in v4 which make it almost magical. Once RadSec is done, it should be trivial to do bizarre things like DNS over TLS. I'm not entirely sure why we'd do that, but it would be trivial to do.
We're looking forward to it very enthusiastically.
Did get one segv, but only when the server was badly misconfigured.
:( If you can report SEGVs, that would help. Even with various static analysis / AI analysis / fuzzers, there are still issues. As an FYI, while many Open Source projects are getting hammered by AI bug reports, we're not. We spent quite a bit of time in February frantically fixing v3 and v4, in expectation of getting flooded with third-party AI reports. The result is that we've received about 10 AI security reports in the last six months. So that's a pretty good track record. Alan DeKok.
Alan DeKok via Freeradius-Users <freeradius-users@lists.freeradius.org> wrote:
If you can report SEGVs, that would help. Even with various static analysis / AI analysis / fuzzers, there are still issues.
I'll see if I can remember how to get it to happen the next go-around with our test server, but it was something like having an auth-type ask for a module that was not configured at all in the next section. Not something that would happen to an actual functioning server.
That’s great news to read on a Saturday morning! Thanks! To be honest, the biggest headache for me right now isn't related to RADIUS for access users (802.1x, VPNs, Wireless, B-RAS, and BNGs). We already have a pretty good handle on that—knowing which stepping stones are solid and which ones are loose in the river. My greatest hope lies in the realm of management access control—specifically, having TACACS+ and RADIUS working together and leveraging the same match conditions to avoid duplicating operational work. I’m very happy to hear about the beta planned for roughly three months from now. But I’d like to make a request: Please release an alpha version of v4 "as-is"—as an actual release, not just a branch or a tag. It might seem like a silly request... But beyond believing it would encourage testing of the v4 alpha right away, I also think the "crazy folks" who spend tokens on security scans for open-source projects would be encouraged to spend that money on your software. Sure, you’ll get a lot of junk back. But it’s likely that something useful could be salvaged from it. Em sex., 25 de set. de 2026 às 12:25, Alan DeKok via Freeradius-Users < freeradius-users@lists.freeradius.org> escreveu:
On Sep 25, 2026, at 11:15 AM, Brian Julin <BJulin@clarku.edu> wrote:
Fantastic! Our initial fiddling with v4 on a test server has been very promising. (RadSec not being a blocker for us, actually.)
Yes, there are a lot of people who don't need RadSec. Or at least, don't need it immediately.
I was actually able to use the detach feature to pre-cache AD group and CPPM RBAC attribute lookups while TLS negotiation was still ongoing for a client. Should be a very welcome speed improvement and untangle a bit of unnecessary and cretinous proxy daisy chaining.
Nice! There are a _ton_ of new features in v4 which make it almost magical.
Once RadSec is done, it should be trivial to do bizarre things like DNS over TLS. I'm not entirely sure why we'd do that, but it would be trivial to do.
We're looking forward to it very enthusiastically.
Did get one segv, but only when the server was badly misconfigured.
:(
If you can report SEGVs, that would help. Even with various static analysis / AI analysis / fuzzers, there are still issues.
As an FYI, while many Open Source projects are getting hammered by AI bug reports, we're not. We spent quite a bit of time in February frantically fixing v3 and v4, in expectation of getting flooded with third-party AI reports.
The result is that we've received about 10 AI security reports in the last six months. So that's a pretty good track record.
Alan DeKok.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Douglas Fernando Fischer Engº de Controle e Automação
On 26/09/2026 12:13, Douglas Fischer wrote:
Please release an alpha version of v4 "as-is"—as an actual release, not just a branch or a tag.
Devel packages get built fairly regularly. Feel free to try :) https://packages.inkbridgenetworks.com/freeradius-devel-4.0/ An 'alpha' release 'as-is' would only really be one of these with a tag on it. -- Matthew
On Sep 26, 2026, at 7:13 AM, Douglas Fischer <fischerdouglas@gmail.com> wrote:
That’s great news to read on a Saturday morning! Thanks!
You're welcome.
To be honest, the biggest headache for me right now isn't related to RADIUS for access users (802.1x, VPNs, Wireless, B-RAS, and BNGs). We already have a pretty good handle on that—knowing which stepping stones are solid and which ones are loose in the river.
That's good to hear.
My greatest hope lies in the realm of management access control—specifically, having TACACS+ and RADIUS working together and leveraging the same match conditions to avoid duplicating operational work.
v4 support TACACS+ for precisely this reason. It's done the FreeRADIUS way, so it's a little different than "traditional" TACACS+ servers. But the result is (we think) more powerful.
I’m very happy to hear about the beta planned for roughly three months from now. But I’d like to make a request: Please release an alpha version of v4 "as-is"—as an actual release, not just a branch or a tag.
As Matthew noted, v4 builds are available every day. And, nothing goes into v4 unless all of the 1000's of CI tests pass. So while there might be issues, the code is exhaustively tested.
It might seem like a silly request... But beyond believing it would encourage testing of the v4 alpha right away, I also think the "crazy folks" who spend tokens on security scans for open-source projects would be encouraged to spend that money on your software. Sure, you’ll get a lot of junk back. But it’s likely that something useful could be salvaged from it.
See my previous message, we've already done that, and we're continuing to do it. Alan DeKok.
participants (5)
-
Alan DeKok -
Alan DeKok -
Brian Julin -
Douglas Fischer -
Matthew Newton