Version 1.1.1 has been released
Version 1.1.1 has just been released. http://www.freeradius.org/security.html Upgrade now, or disable EAP-MSCHAPv2. That's a bad bug. ChangeLog: Security fixes * Additional state checking in the EAP-MSCHAPv2 module. Bug found by Steffen Schuster. Feature improvements * More dictionary updates * Additional tests and fixes for Digest module from Phillipe Sultan. * Add new "phone" response mode to rlm_otp/cryptocard. * Put the eap sessions into a tree, so that looking them up is very fast, and no longer O(n) in the number of sessions. * Install the schema examples for a set of backends with the rest of the documentation. * Add support for xlat expansion of attributes from LDAP. Bug fixes * Fix rlm_perl crash. (closes: #348) * Fix handling of CoA-Request packets (close #344). Also correct name of CoA packets. * Fix an error on x86_64 machines when reading dictionaries. (closes: #312) * Fix compilation errors on FreeBSD and NetBSD because of rlm_otp module. (closes: #314 #328) * Workaround Cisco bug in State attribute handling in rlm_otp. * Support LP64 for async mode in rlm_otp. * Fix libtool problems on Debian with rlm_eap_peap and rlm_eap_ttls modules. (closes: #75) * Make "use_tunneled_reply" work properly for PEAP. * Copy the whole string when getting a one-to-one-mapped attribute from LDAP (closes: #261) * Fix net-snmp's ucd-snmp compatibility mode.
Hi, as I see, #335 didn't make it. Any particular reason or did it just get lost? IIRC, adding it was considered okay? Greetings, Stefan -- Stefan WINTER Stiftung RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche Ingenieur Forschung & Entwicklung 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg E-Mail: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
Stefan Winter <stefan.winter@restena.lu> wrote:
as I see, #335 didn't make it. Any particular reason or did it just get lost? IIRC, adding it was considered okay?
Time & validation. 1.1.1 had already been delayed a lot. We should really have a schedule for monthly releases. Alan DeKok.
Stefan Winter <stefan.winter@restena.lu> writes:
as I see, #335 didn't make it. Any particular reason or did it just get lost? IIRC, adding it was considered okay?
I do of course not know why it was left out, but I noticed the following discussion a few days ago: aland: "If it doesn't change existing behavior, I'm OK with adding it in." stefan.winter: "existing behaviour is unchanged." So far, so good. But then you went on describing that existing behaviour in fact IS changed: "The speed-up is very marginal, but: as of yet, for every packet this if () condition is evaluated, and and in the vast majority of cases (whenever User-Name is present) it evals to true. After taking these lines out, the if eval is saved (kinda being true always). Overall, you save one boolean evaluation per packet." I understand that this change is what you want, but there MAY be someone depending on the existing behaviour. This change will then surely break their current working configuration. They can of course fix it by reconfiguring the server, taking this change into consideration, but that is NOT the way to do a stable release cycle. All above IMHO, of course. Bjørn
Hi,
I understand that this change is what you want, but there MAY be someone depending on the existing behaviour. This change will then surely break their current working configuration. They can of course fix it by reconfiguring the server, taking this change into consideration, but that is NOT the way to do a stable release cycle.
My explanation was intended only to explain why packet handling gets a tiny little bit faster. But you are right, there is a very minimal impact: normal packets (with User-Name) are always passed through hints, this is unchanged. So, the only new behaviour is that packets without User-Name attribute are also passed through hints, which indeed is new. However, it would only break an existing configuration iff someone relies on the fact that his Accounting-On-Off packets are ignored in the hints run. I don't want to judge on that, but it sure sounds odd if your configuration relies on that. The patch would add consistency where it wasn't before, which is a very good thing IMHO. But I also see your concerns. Stefan -- Stefan WINTER RESTENA Foundation - Réseau Téléinformatique de l'Education Nationale et de la Recherche R&D Engineer 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg email: stefan.winter@restena.lu Tel.: +352 424409-1 http://www.restena.lu Fax: +352 422473
On Wed, 2006-22-03 at 08:22 +0100, Stefan Winter wrote:
Hi,
I understand that this change is what you want, but there MAY be someone depending on the existing behaviour. This change will then surely break their current working configuration. They can of course fix it by reconfiguring the server, taking this change into consideration, but that is NOT the way to do a stable release cycle.
My explanation was intended only to explain why packet handling gets a tiny little bit faster. But you are right, there is a very minimal impact: normal packets (with User-Name) are always passed through hints, this is unchanged. So, the only new behaviour is that packets without User-Name attribute are also passed through hints, which indeed is new. However, it would only break an existing configuration iff someone relies on the fact that his Accounting-On-Off packets are ignored in the hints run. I don't want to judge on that, but it sure sounds odd if your configuration relies on that.
The patch would add consistency where it wasn't before, which is a very good thing IMHO. But I also see your concerns.
Stefan The problem I mentioned, when this was brought up, was that the intention for doing this was to use hints for something it was not meant for.
I think it would be better to use hints as a template for a new module that does specifically what you want. If someone wants the functions the new module is designed for, they can configure it in pre-processing or where ever it is required. I don't use hints anymore, but other users who are not privy to the developers list may.
I would like to suggest that we setup freeradius-announce@lists.freeradius.org to allow people who are not subscribed to the user or devel list but still want to be notified of new releases and security issues. All release info should be cross posted to it as well as the usual places. Cheers Peter On Tue 21 Mar 2006 00:52, Alan DeKok wrote:
Version 1.1.1 has just been released.
http://www.freeradius.org/security.html
Upgrade now, or disable EAP-MSCHAPv2. That's a bad bug.
ChangeLog: Security fixes * Additional state checking in the EAP-MSCHAPv2 module. Bug found by Steffen Schuster.
Feature improvements * More dictionary updates * Additional tests and fixes for Digest module from Phillipe Sultan. * Add new "phone" response mode to rlm_otp/cryptocard. * Put the eap sessions into a tree, so that looking them up is very fast, and no longer O(n) in the number of sessions. * Install the schema examples for a set of backends with the rest of the documentation. * Add support for xlat expansion of attributes from LDAP.
Bug fixes * Fix rlm_perl crash. (closes: #348) * Fix handling of CoA-Request packets (close #344). Also correct name of CoA packets. * Fix an error on x86_64 machines when reading dictionaries. (closes: #312) * Fix compilation errors on FreeBSD and NetBSD because of rlm_otp module. (closes: #314 #328) * Workaround Cisco bug in State attribute handling in rlm_otp. * Support LP64 for async mode in rlm_otp. * Fix libtool problems on Debian with rlm_eap_peap and rlm_eap_ttls modules. (closes: #75) * Make "use_tunneled_reply" work properly for PEAP. * Copy the whole string when getting a one-to-one-mapped attribute from LDAP (closes: #261) * Fix net-snmp's ucd-snmp compatibility mode. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Peter Nixon http://www.peternixon.net/ PGP Key: http://www.peternixon.net/public.asc
participants (5)
-
Alan DeKok -
Bjørn Mork -
Guy Fraser -
Peter Nixon -
Stefan Winter