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