A preview release of 3.0.4 is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_4_rc1.ta... We’re creating a second release candidate for 3.0.4 to verify defects in the last release candidate have been fixed, and that no new issues have crept in. Some changes since the last RC: Compile time type checking ------------------------------------- In response to the particularly nasty subtle corruption of memory in FreeRADIUS 3.0.3 caused by mismatched variable/configuration directive types and the configuration parser, we’ve added compile time checking. https://github.com/FreeRADIUS/freeradius-server/blob/master/src/include/conf... This has involved a large amount of code churn as field types in module configuration structs have been altered to match exactly the configuration directive type. The most use visible part of these changes is that integer type configuration directives will, in most cases, no longer accept negative values. If you find a particular integer type configuration directive that you feel should accept negative integers, let us known and we'll correct it. Client / homeserver / listener changes ------------------------------------------------- One of the other changes forced by compile time type checking was for IP/IPv4/IPv6 types. All addresses and prefixes in modules and the server core, are now represented as fr_ipaddr_t. This means some places which would only accept IPv4 addresses before now accept IPv4 prefixes and IPv6 addresses/prefixes. Internal attribute numbering ------------------------------------- Following the same theme of preventing mismatches within the server, the internal macros used for attribute numbering are now auto-generated at build time. This should prevent mismatches occurring between the shipped dictionary and the header files, and allows users building from src to renumber internal attributes (if they really want to) by editing the share/dictionary.freeradius.internal dictionary and recompiling. rlm_cache behaviour changes ---------------------------------------- One of the things that has prevented people using the rlm_cache module is it’s perceived complexity. To make things similar we’ve introduced a couple of behaviour changes. Firstly the module will consume any of the control attributes used to configure it after each call. The second change was to add the Cache-Read-Only attribute, which will allow merging of existing cache entries but will prevent new ones being created. For caching attributes from LDAP you’d now do something like: update control { Cache-Read-Only := yes } cache # Consumes Cache-Read-Only if (notfound) { ldap cache } Which is a little simpler than: update control { Cache-Status-Only := yes } cache update control { Cache-Status-Only := no } if (notfound) { ldap } cache It’s also more efficient as for cached entries there’s only a single lookup. This shouldn’t affect the majority of installations already using rlm_cache, for most, it will just make some update blocks redundant. If you run into any issues log a report at http://bugs.freeradius.org, or post to the list. -Arran
I'm having a little inconvenience with the generated Debian packages, they fail to start, trying to protect you from the heartbleed bug Mon Jun 2 12:33:57 2014 : Error: Refusing to start with libssl version OpenSSL 1.0.1e 11 Feb 2013 0x01000105f (1.0.1e-15) (in range 1.0.1-0 - 1.0.1f-15) Mon Jun 2 12:33:57 2014 : Error: Security advisory CVE-2014-0160 (Heartbleed) Mon Jun 2 12:33:57 2014 : Error: For more information see http://heartbleed.com However, this issue has been backported by Debian in libssl version 1.0.1e-2+deb7u5. A fix for this has been propesed and merged in #590 <https://github.com/FreeRADIUS/freeradius-server/pull/590>. However, this fix got reverted in commit 55a7773512221d698beb02bc6e36e8585b63fe60, without a real explanation (just the standard "this reverts commit xyz" message). Is there any specific reason that this fix has been reverted? -- Herwin Weststrate On 01-06-14 20:35, Arran Cudbard-Bell wrote:
A preview release of 3.0.4 is available here: https://github.com/FreeRADIUS/freeradius-server/archive/release_3_0_4_rc1.ta...
We’re creating a second release candidate for 3.0.4 to verify defects in the last release candidate have been fixed, and that no new issues have crept in.
Some changes since the last RC:
Compile time type checking ------------------------------------- In response to the particularly nasty subtle corruption of memory in FreeRADIUS 3.0.3 caused by mismatched variable/configuration directive types and the configuration parser, we’ve added compile time checking.
https://github.com/FreeRADIUS/freeradius-server/blob/master/src/include/conf...
This has involved a large amount of code churn as field types in module configuration structs have been altered to match exactly the configuration directive type. The most use visible part of these changes is that integer type configuration directives will, in most cases, no longer accept negative values.
If you find a particular integer type configuration directive that you feel should accept negative integers, let us known and we'll correct it.
Client / homeserver / listener changes ------------------------------------------------- One of the other changes forced by compile time type checking was for IP/IPv4/IPv6 types. All addresses and prefixes in modules and the server core, are now represented as fr_ipaddr_t.
This means some places which would only accept IPv4 addresses before now accept IPv4 prefixes and IPv6 addresses/prefixes.
Internal attribute numbering ------------------------------------- Following the same theme of preventing mismatches within the server, the internal macros used for attribute numbering are now auto-generated at build time. This should prevent mismatches occurring between the shipped dictionary and the header files, and allows users building from src to renumber internal attributes (if they really want to) by editing the share/dictionary.freeradius.internal dictionary and recompiling.
rlm_cache behaviour changes ---------------------------------------- One of the things that has prevented people using the rlm_cache module is it’s perceived complexity.
To make things similar we’ve introduced a couple of behaviour changes. Firstly the module will consume any of the control attributes used to configure it after each call.
The second change was to add the Cache-Read-Only attribute, which will allow merging of existing cache entries but will prevent new ones being created.
For caching attributes from LDAP you’d now do something like: update control { Cache-Read-Only := yes } cache # Consumes Cache-Read-Only if (notfound) { ldap cache }
Which is a little simpler than:
update control { Cache-Status-Only := yes } cache update control { Cache-Status-Only := no } if (notfound) { ldap } cache
It’s also more efficient as for cached entries there’s only a single lookup.
This shouldn’t affect the majority of installations already using rlm_cache, for most, it will just make some update blocks redundant.
If you run into any issues log a report at http://bugs.freeradius.org, or post to the list.
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Hi,
Is there any specific reason that this fix has been reverted?
there is no way of knowing if a backport has been applied....its based on just the version...and unfortunately they backported fix rather than push out the new version.... just change allow_vulnerable_openssl = no to allow_vulnerable_openssl = yes in radiusd.conf if you believe that your OpenSSL package that is currently installed on your system is safe/fixed (well, for heartbleed at least! ;-) ) alan
On 2 Jun 2014, at 11:55, Herwin Weststrate <herwin@quarantainenet.nl> wrote:
I'm having a little inconvenience with the generated Debian packages, they fail to start, trying to protect you from the heartbleed bug
Mon Jun 2 12:33:57 2014 : Error: Refusing to start with libssl version OpenSSL 1.0.1e 11 Feb 2013 0x01000105f (1.0.1e-15) (in range 1.0.1-0 - 1.0.1f-15) Mon Jun 2 12:33:57 2014 : Error: Security advisory CVE-2014-0160 (Heartbleed) Mon Jun 2 12:33:57 2014 : Error: For more information see http://heartbleed.com
However, this issue has been backported by Debian in libssl version 1.0.1e-2+deb7u5. A fix for this has been propesed and merged in #590 <https://github.com/FreeRADIUS/freeradius-server/pull/590>. However, this fix got reverted in commit 55a7773512221d698beb02bc6e36e8585b63fe60, without a real explanation (just the standard "this reverts commit xyz" message).
Is there any specific reason that this fix has been reverted?=
Yes. It broken Ubuntu builds as Ubuntu had a different name for the libssl package. I've requested a couple of times for someone who has more knowledge of Debian packaging to write a fix which will work for both Debian and Ubuntu. Will someone please send a pull request which will work for both Debian and Ubuntu... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Herwin Weststrate wrote:
However, this issue has been backported by Debian in libssl version 1.0.1e-2+deb7u5.
It's impossible for FR to figure that out at run-time. It's difficult to figure it out when building the Debian package, too. Any *official* debian / Ubuntu package should set the OpenSSL flag in the radiusd.conf file. For everyone else, it's better for us to ship a safe and secure version of FR. Alan DeKok.
participants (4)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Arran Cudbard-Bell -
Herwin Weststrate