Hi Chris, I am sorry that I didn't get around to reply your email before now. I had to work with the client library on one of the projects at work and found some more areas that could needs some improvements. I guess some of these could be considered for version 2.0 of the client library. 1) Documentation I find it sometimes hard to find information outside some of the function without looking at the code, and I guess you can look into the man page. An good idea as the project moves forward is to perform some documentation of the globally exported functions such as rc_config_add(...), etc. I've had to do some work evolving round the libnl (or netlink from the netfilter guys), this project uses doxygen to generate the documentation for the APIs in html format (with option for PDF, etc). The API for freeradius-client is pretty simple, but it sure wold be nice. Doxygen might be one way of doing this, but the project may have a different favorite. My point was mainly documentation. 2) Restructuring of the core logic I personally like to re-factor the rc_auth(), group of functions and to break them out into using something similar to a rc_send(fd, handle, ...). Some applications may not want to have a blocking interface, and rather have an API that allows a) service of multiple requests, b) continue to work on other tasks asynchronously of the request / response. Comparing it to the BSD version libradius, it has an API to perform these operations. And I find it a bit more flexible. And there exist a patches to make it work with the TACAS+ server. Point is, the API is more flexible to do such things as mentioned above. 3) Some attributes require additional processing Working over this, I found some of the Microsoft attributes a bit tougher to work through. The MS_MPPE_SEND_KEY and MS_MPPE_RECV_KEY required decryption using the secret and the random vector sent to the server. This isn't explicitly exported / allowed so I had to *hack* it to get around the problem. This can obviously be solved in many different ways, and reading the code I get the impression that the 'secret' is not to be exposed longer than it needs to. I don't understand why it would be a concern since the 'secret' is resident in memory since you embed it into you application. That is of course if you don't read it from a configuration file with proper file attributes. Regardless, I am starting to think that what you really would like to do in cases for odd-ball attributes like these is to have the application provide a callback interface in which it is passed to the API and once you finally have validated the properties, then you walk the list of attributes and if the attribute matches then call the registered callback function for that property. 4) Use of OpenSSL I see that the project provides their own implementation of MD5. I am an embedded developer and this makes me concerned in two ways: 1) additional code, larger footprint, 2) linking with freeradius-client and openssl may have consequences. I've debugged one time too many where code calls MD5_Init() within the wrong library and if one implementation is broken then you can just imagine -- you spend ours banging your head in the wall. It would be nice if configure could figure out whether or not you have md5.h, and link with openssl instead of using the provided version. 5) Other Projects I don't know how much this matter much but I think it would be very nice if freeradius-client (with help of configure) could compile modules for applications in which you have installed on your system. In this way Third Party Software like pppd, openser, openvpn, you name your favorite here. Could use freeradius-client from the latest sources. I know this may a bit much to ask and it may have some negative aspects, like they make a modification to their interface and now the module changes, backward compatibility, etc. On the other hand, I think the positives would be to prevent e.g. a fork of the project. Each project do it a bit different, e.g. pppd provide their own. Bug fixes doesn't always make it upstream, etc... If the motivator is "one-stop-shop for radius authentication", then this might be interesting. So Chris, does there exist a version 2.0 branch in CVS? In case, you think some of the above is interesting and I can give you some time to implement these, what is the code/patch submission policies? Are you other freeradius-client developers available on IRC? Best Regards, - Eivind On Nov 12, 2007 1:50 PM, Chris Parker <cparker@starnetusa.net> wrote:
On Nov 12, 2007, at 3:25 PM, Eivind Naess wrote:
Hi Freeradius-client developers!
I have a couple of questions regarding the freeradius-client project.
1) When is freeradius-client-1.1.6 being released?
In the near future. Before 2008.
There's some segfaults reported by the OpenSER folks that I want to handle a little better. Admittedly, they are not embedding it the way that it's now designed to be embedded, but I think we can at least return an error rather than SEGV.
2) Is there any roadmap for the freeradius-client, any chance that I could help participate taking it to version 2.0? In case what are the features being worked on?
1.x:
Overall Goal: Introduce embedded capabilities, while maintaining backwards compat as much as possible.
o Internalize sequence number handling ( not use external file ) o Expand cross-platform support o Improve cross-compiling
2.x:
Overall Goal: Improve embedded capabilities. No requirement to maintain backwards compat.
o Restructure code/logic in more sensible manner, since we're not constrained by backwards compat. o Include standard RFC attributes via header, so no external dictionary needed for those. o Add ability to pass VSA attributes via config option on initialization.
Other suggestions as to what the community/users of the client lib are looking for are certainly welcome. Code/patches/testing/feedback also very welcome.
-Chris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/devel.html