[ANN] Release 3.0.4 rc1

[Herwin Weststrate]

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.tar.gz
> 
> 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/conffile.h#L44
> 
> 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
>