What is the current status and roadmap for FreeRadius?

[Arran Cudbard-Bell]

> On Mar 16, 2019, at 2:47 AM, Joshua Marshall <j.marshall at arroyo.io> wrote:
> 
> Thank you for the speedy reply.  We're implementing stuff with FreeRadius
> and are having to abuse it in a few unorthodox ways.  Config files with
> silent errors or misconfigurations, using what seems to be undocumentd
> interactions with LDAP to handle passwords securely -- challenges which
> feel like they're from a bygone era.

If you could provide some actual concrete examples of the above, then I'm sure
the issues could be addressed.

Having written the majority of the LDAP code I have to say I have no idea what
you're talking about regarding "undocumented interactions".

There are four methods of authenticating users with LDAP:

- Retrieving the password hash with a search operation and comparing the hash
  with the received password.
- Binding to LDAP using a simple bind with the user's plaintext password and
  using the result of that operation to decide on whether the user should be
  authenticated or not.
- Binding to LDAP with a SASL bind.
- Using eDirectory's Universal Password feature to retrieve the cleartext password
  for the user.

All of these are well documented.

> Looking at the roadmap, and you've probably had to answer these before, why
> not switch the codebase to C++ which has wrapped up much of the threading

Last time I checked it didn't have any better support for stack suspension and
resumption than C does which is one of the issues which has taken a
significant amount of time.

When your target is millions of requests in flight simultaneously, stack memory
usage, parallelisation, network data path and memory zone alignment,
and asynchronous I/O are the main issues you end up hitting.

We already offload memory management to libtalloc, eventing to libkqueue
and crypto to OpenSSL, and use tens of other auxiliary libraries in the modules.

> and modularization work already

Not an actual issue we've faced.

> and has a number of good libraries to
> handle networking?

Not an actual issue we've faced.

>  Why not use Antlr4 to run your grammars and make start
> and runtime problems more apparent as well as providing a more robust
> parsing method?

It doesn't currently have a code generation target for C, and you provided
absolutely no compelling reasons to switch the code base to C++.

> What we are really feeling over here is a lack of modern behavior and
> features.

As someone who's done multiple, complex, commercial deployments with
FreeRADIUS I disagree.

If you don't like the policy language or feel that you'd be more at home writing
all your business logic in C++, you can wrap it in a REST API and punt
the request processing over to an external process using the REST module.

Or you can use the Python, Perl, Mruby or Lua embedded interpreters.

The reality is though, that the policy language is sufficient for the vast majority
of deployments.

What a lot of people miss is that the policy language actually does a pretty
excellent job of handling the simple cases, in that it requires the users to
have absolutely zero programming knowledge and configuration is done
by shuffling module call orders around.

> Which isn't just one thing, but an enormous amount of work and
> polish.

I disagree.

>  That isn't a thing we could ever just ask for and get -- it iosn't
> that easy and we know that.

I disagree.

>  But to know what is OK to ask and what might
> be possible requires context.

Not sure what you mean here as the context is ambiguous.

-Arran

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20190316/045aa1f9/attachment.sig>