Created attachment 6770 [details]
Patch freeradius in order not to fail in case of a libssl version mismatch (still prints the error)

Created attachment 6771 [details]
modification of freeradius.spec to use previous patch

I rebuilt the rpm using this patch. On the build machine neither it fails nor prints the error (obviously, since it has the same openssl libraries used to build it), but I copied freeradiusd to the affected server (still running mga4) and tested it with -CX and it prints the error but it doesn't fail.
Note that this patch (or a similar one) will most probably be also needed after fixing bug #16175

I now upgraded again the VM to mga5, then installed my updated freeradius RPMs with the patch and it works (at least with my configuration, which is to authorize wireless clients).

Mmh, I reckon my last comment was somewhat redundant: as I said in comment 2 this self compiled rpm obviously has no libssl version mismatch.

This was fixed upstream somewhere between 2.2.3 and 2.2.8.  The update will be on its way to QA shortly in Bug 16175.

OK, I hope that this commit really obviates the need for the patch:

https://github.com/FreeRADIUS/freeradius-server/commit/5ae2a70a135062a025d8fabc104eeae3a2c53a7a

(though I'm not 100% sure)

Nope, it doesn't work:

[luca@unifi updates-testing]$ rpm -qa | grep freeradius
lib64freeradius1-2.2.8-1.mga5
freeradius-ldap-2.2.8-1.mga5
freeradius-2.2.8-1.mga5
[luca@unifi updates-testing]$ sudo systemctl start radiusd
Job for radiusd.service failed. See "systemctl status radiusd.service" and "journalctl -xe" for details.
[luca@unifi updates-testing]$ sudo /usr/sbin/radiusd -CX | tail -n1
libssl version mismatch.  built: 1000204f linked: 1000203f

And that's because the new package has been built with openssl from updates-testing (1.0.2d) while openssl on my (fully up to date) system is 1.0.2c.
If those openssl version are binary compatible, I suggest to use the option --disable-openssl-version-check

https://github.com/FreeRADIUS/freeradius-server/commit/767c67fc4f2f673a44f89794a3531158dcb7b1ec

to avoid this kind of problems.

There is no problem.  See https://bugs.mageia.org/show_bug.cgi?id=16175#c4

The latest openssl update broke it again

Can confirm the new breakage :

# rpm -qa --last | egrep '^openssl|^freeradius'
openssl-1.0.2e-1.mga5.x86_64                  Sun 06 Dec 2015 09:27:51 AEDT
freeradius-2.2.8-1.1.mga5.x86_64              Fri 30 Oct 2015 17:17:44 AEDT

When starting :

Error: libssl version mismatch.  built: 1000204f linked: 1000205f

A local rpmbuild of freeradius-2.2.8-1.1.mga5.src.rpm fixes this.

CC: (none) => rod.emerson

This error shouldn't be happening.  Does upstream have a newer patch to actually fully fix this?

CC: (none) => luigiwalser
Keywords: PATCH => (none)

There is --disable-openssl-version-check

And a change in that area 9 days ago :
https://github.com/FreeRADIUS/freeradius-server/pull/1441

http://comments.gmane.org/gmane.comp.freeradius.devel/12029

@Rod
Is it possible to get a download link to your local build rpm in between? Since my server restart tomorrow morning the service is not starting due to this error. Otherwise i will have to download all the dependencies to build the srpm on my own because I need that service running again...

CC: (none) => s.puch

(In reply to Rod Emerson from comment #13)
> There is --disable-openssl-version-check
> 
> And a change in that area 9 days ago :
> https://github.com/FreeRADIUS/freeradius-server/pull/1441
> 
> http://comments.gmane.org/gmane.comp.freeradius.devel/12029

And reading through all that, I can see that this is not the option you're looking for.  It disables checks for old versions of OpenSSL that are vulnerable to Heartbleed, but it doesn't disable the check for the compile-time/runtime version mismatch.  I don't see an option for that.  The way that check is supposed to work is it is supposed to allow it if the system version is newer than or equal to the version it was compiled against.  If that's not working, please report it upstream.  We can rebuild this once we get a proper fix.

(In reply to Stefan Puch from comment #14)
http://users.on.net/~emerson/freeradius/

(In reply to David Walser from comment #15)
Version 2.x is EOL, others have either rebuilt against current openssl
or print the error but do not fail as far as I can see :

--- ./freeradius-server-2.2.8/src/main/version.c
+++ ./freeradius-server-2.2.8/src/main/version.c
@@ -77,7 +77,7 @@
                radlog(L_ERR, "libssl version mismatch.  built: %lx linked: %lx",
                       (unsigned long) ssl_built, (unsigned long) ssl_linked);
 
-               return -1;
+               /* return -1; */
        }
 
        /*

The comments in version.c say "only allow moving backwards within 
a patch series" so I guess this is working as designed but I do not
pretend to understand the SSLeay tests they do, according to the error
we moved forward, 4f to 5f.

(In reply to Rod Emerson from comment #16)
> (In reply to David Walser from comment #15)
> Version 2.x is EOL

Ouch!

> others have either rebuilt against current openssl

We can't do that every time we update openssl.

> or print the error but do not fail as far as I can see :

The message is useless, it should be disabled completely.

> --- ./freeradius-server-2.2.8/src/main/version.c
> +++ ./freeradius-server-2.2.8/src/main/version.c
> @@ -77,7 +77,7 @@
>                 radlog(L_ERR, "libssl version mismatch.  built: %lx linked:
> %lx",
>                        (unsigned long) ssl_built, (unsigned long)
> ssl_linked);
>  
> -               return -1;
> +               /* return -1; */
>         }
>  
>         /*
> 
> The comments in version.c say "only allow moving backwards within 
> a patch series" so I guess this is working as designed but I do not

No, it isn't working as designed.  It's supposed to be OK as long as it was built against the same or an older version within the same patch series.

> pretend to understand the SSLeay tests they do, according to the error
> we moved forward, 4f to 5f.

Right, that's their way of encoding the letter part of 1.0.2d and 1.0.2e.

(In reply to Rod Emerson from comment #16)
> http://users.on.net/~emerson/freeradius/
Thanks Rod! Unfortunatly I need an x86 build...
I will try to rebuild that version in my virtual machine.

> Version 2.x is EOL
Would it be an option in this "special" case to move forward to a supported Version (3.x)? If someone would push a Version 3 build e.g. to testing tree I would contribute with testing...

(In reply to Stefan Puch from comment #18)
> > Version 2.x is EOL
> Would it be an option in this "special" case to move forward to a supported
> Version (3.x)? If someone would push a Version 3 build e.g. to testing tree
> I would contribute with testing...

I think that would be OK.  This package has no maintainer, so someone needs to do the work of updating it.

(In reply to David Walser from comment #19)
> I think that would be OK.  This package has no maintainer, so someone needs
> to do the work of updating it.

Well, I'm no expert in maintaining a package but I tried to combine/upgrade/fix the spec file from freeradius-2.2.8-1.1.mga5.src.rpm with all necessary stuff to build freeradius-3.0.10. Therefore I did a look into the spec file from Fedora 24. Maybe the OpenSSL problem discussed in this bug will be solved, too (Fix OpenSSL version parsing when checking for compatibility at run time. https://bugzilla.redhat.com/show_bug.cgi?id=1173821#c11)

I will attach the output here for further review/testing, because there were many changes in freeradius version3.

in short:
- I dropped all patch from version 2.x
- I did a rediff for patch0 (ssl-config)
- on an x86 system 'rpmbuild -ba freeradius.spec' works fine while still some warnings are present
- some modules are silently not build (see freeradius-3-WARNING.log from configure script)
- I did NOT install / test the outcome RPMS until now

--> but maybe some with more experience can catch up the ball from here?
Any comments are welcome...

Created attachment 7293 [details]
WARNINGS of modules not build

Created attachment 7294 [details]
ssl-config-patch-freeradius-3.0.10

Created attachment 7295 [details]
draft-spec-file-freeradius-3.0.10

(In reply to Stefan Puch from comment #21)
> Created attachment 7293 [details]
> WARNINGS of modules not build

Some of these can be fixed by adding BuildRequires for json-c-devel and libiodbc-devel.  In Cauldron we can add wbclient-devel as well (we can't do that in Mageia 5 until the Samba 4 migration is completed).

(In reply to Stefan Puch from comment #22)
> Created attachment 7294 [details]
> ssl-config-patch-freeradius-3.0.10

This patch appears to have many mistakes.  The package calls the SSL key and cert radiusd.pem and the key is in ${system_ssldir}/private and the cert is in ${system_ssldir}/certs.  These files should always end in .pem and not .crt (except for the CA cert file).  Some of the other things (like redefining /dev/urandom) also don't look right.

As for the SPEC, are you sure it was OK to remove all of the patches?

(In reply to David Walser from comment #25)
> This patch appears to have many mistakes.  The package calls the SSL key and
> cert radiusd.pem and the key is in ${system_ssldir}/private and the cert is
> in ${system_ssldir}/certs.  These files should always end in .pem and not
> .crt (except for the CA cert file).
You are right, there where some mistakes made from me, but some of the files end where exactly that way and I just changed the path.
(e.g. ca_file = ${certdir}/cacert.pem and certificate_file = /path/to/radius.crt)

I'll update the patch above, then you can review it again.

> Some of the other things (like redefining /dev/urandom) also don't look right.
Redefining the /dev/urandom is that what the old patch (freeradius-2.1.11-ssl-config.patch) did. I just adapted that, but cannot estimate if that is right...

> As for the SPEC, are you sure it was OK to remove all of the patches?
Patch1:	freeradius-server-2.1.6-fix-format-errors.patch
Is fixed in rlm_ruby.c in line 106

Patch4:	 freeradius-0.8.1-use-system-com_err.patch
Fixed an include of com_err.h in rlm_krb5.c. The include does not exist anymore.

Patch6:	 freeradius-server-2.2.0-avoid-version.diff
Patch7:	 freeradius-server-2.1.10-version-info.diff
As far as I understand patches compiler fags in *.mak / Makefiles which are not existing in freerdius version 3 (not 100% sure)

Patch8:	 freeradius-2.0.0-samba3.patch
I did not find any corresponding file / code when grepping through the code

Patch9:	 freeradius-server-2.1.8-ltdl_no_la.patch
This new source code is completely rewritten. Someone with more C experience will have to look at it and decide if it is still necessary --> tbd

Patch10: freeradius-server-linkage_fix.diff
Patch to add link against OPENSSL_LIBS. From my kind of understanding this is included in Make.inc in freeradius 3 code

Patch11: freeradius-server-2.1.7-fix-perl-scripts.patch
Patch for dialup_admin which was completely removed in freeradius version 3

Patch12: freeradius-server-2.2.0-yubico-paths.diff
Patch for rlm_yubikey.c which was included into freeradius 3 source code (in freeradius 2 that module was added from external source http://code.google.com/p/freeradius-yubikey-module/)

Created attachment 7299 [details]
ssl-config-patch-freeradius-3.0.10

Attachment 7294 is obsolete: 0 => 1

(In reply to David Walser from comment #24)
> Some of these can be fixed by adding BuildRequires for json-c-devel and
> libiodbc-devel.  In Cauldron we can add wbclient-devel as well (we can't do
> that in Mageia 5 until the Samba 4 migration is completed).
I updated spec file with BuildRequires for libjson-devel and libiodbc-devel.
I added a note for "Samba must be version 4.2.1" and commented out BuildRequires for wbclient-devel so that it still builds with Mageia 5.

Created attachment 7300 [details]
draft-spec-file-freeradius-3.0.10

Attachment 7295 is obsolete: 0 => 1

Created attachment 7301 [details]
WARNINGS of modules not build

Attachment 7293 is obsolete: 0 => 1

(In reply to Stefan Puch from comment #27)
> Created attachment 7299 [details]
> ssl-config-patch-freeradius-3.0.10

I'm not sure if we have to create two or three certs now since there's a radiusd, inner-radiusd, and client one in that config now.  I'm almost certain that redefining /dev/urandom is wrong (I believe it was wrong in the old patch too).  Other than that, nothing stands out as bad now.  Nice job.

(In reply to Stefan Puch from comment #30)
> Created attachment 7301 [details]
> WARNINGS of modules not build

Looks about as good as could be hoped for.  I worry a little bit about that eap-ikev2, that sounds like it might be important.  I wonder why it isn't bundled in FreeRADIUS.  It doesn't look like we have it packaged.

(In reply to Stefan Puch from comment #29)
> Created attachment 7300 [details]
> draft-spec-file-freeradius-3.0.10

Ahh, look at this:
%post
%_tmpfilescreate radiusd
%_post_service radiusd
%create_ghostfile %{_localstatedir}/log/radius/radutmp radius radius 0644
%create_ghostfile %{_localstatedir}/log/radius/radwtmp radius radius 0644
%create_ghostfile %{_localstatedir}/log/radius/radius.log radius radius 0644
%_create_ssl_certificate radiusd -g radius
if [ $1 = 1 ]; then
    openssl dhparam -out  %{_sysconfdir}/raddb/certs/dh 1024 2>&1 >/dev/null
    dd if=/dev/urandom of=%{_sysconfdir}/raddb/certs/random count=10 2>&1 >/dev/null
    chgrp radius %{_sysconfdir}/raddb/certs/random
fi

so I guess redefining /dev/urandom *might* be correct (although dd'ing out 10 bytes and always using those same 10 bytes sounds like an awfully strange thing to do).

You also see there where it creates the radiusd certificate, that's the only one.  So I'm still not sure what to make of the other ones in the new config.

You also see it creating the "dh" file that the config references.  It looks like the path in the commands above may not be the same as what you have in your updated patch; something to double-check.

I think we're getting close.

(In reply to David Walser from comment #31)
> I'm not sure if we have to create two or three certs now since there's a
> radiusd, inner-radiusd, and client one in that config now.  I'm almost
> certain that redefining /dev/urandom is wrong (I believe it was wrong in the
> old patch too).  Other than that, nothing stands out as bad now.  Nice job.
I tend to agree with you. I removed the redefining.

Created attachment 7305 [details]
ssl-config-patch-freeradius-3.0.10

Attachment 7299 is obsolete: 0 => 1

(In reply to David Walser from comment #32) 
> Looks about as good as could be hoped for.  I worry a little bit about that
> eap-ikev2, that sounds like it might be important.  I wonder why it isn't
> bundled in FreeRADIUS.  It doesn't look like we have it packaged.
Looking into the spec file of Fedora Core 24 you can see that they don't build it either. They use --without-rlm_eap_ikev2 during configuration, too.

(In reply to David Walser from comment #33)
> Ahh, look at this:
> %post
> %_tmpfilescreate radiusd
> %_post_service radiusd
> %create_ghostfile %{_localstatedir}/log/radius/radutmp radius radius 0644
> %create_ghostfile %{_localstatedir}/log/radius/radwtmp radius radius 0644
> %create_ghostfile %{_localstatedir}/log/radius/radius.log radius radius 0644
> %_create_ssl_certificate radiusd -g radius
> if [ $1 = 1 ]; then
>     openssl dhparam -out  %{_sysconfdir}/raddb/certs/dh 1024 2>&1 >/dev/null
>     dd if=/dev/urandom of=%{_sysconfdir}/raddb/certs/random count=10 2>&1
> >/dev/null
>     chgrp radius %{_sysconfdir}/raddb/certs/random
> fi
> 
> so I guess redefining /dev/urandom *might* be correct (although dd'ing out
> 10 bytes and always using those same 10 bytes sounds like an awfully strange
> thing to do).
Urgs. I don't know for what reason that *might* be correct. The comment in the config says "If your system doesn't have /dev/urandom you will need to create this file, and periodically change its contents."
1) dd uses /dev/urandom so it is definitely available
2) I cannot see that it is changed ever

As I removed it from the patch it has to be removed here, too.


> You also see there where it creates the radiusd certificate, that's the only
> one.  So I'm still not sure what to make of the other ones in the new config.
I added two lines to create the inner-radiusd and client certificate as well.

 
> You also see it creating the "dh" file that the config references.  It looks
> like the path in the commands above may not be the same as what you have in
> your updated patch; something to double-check.
The updated patch uses ${local_ssldir} for "dh" file, original ${certdir} is used. But when looking into radiusd.conf.in you can see that both are set to ${confdir}/certs so it is just a renaming. In principal it is useless I kept it to make it easier for the users to compare their configs when upgrading...
If you say drop that part I will do so....

Finally I missed to include rlm_rest.so in %files which is fixed now.

Created attachment 7306 [details]
draft-spec-file-freeradius-3.0.10

Attachment 7300 is obsolete: 0 => 1

(In reply to Stefan Puch from comment #38)
> Created attachment 7306 [details]
> draft-spec-file-freeradius-3.0.10

OK, looking at this closer now, just a few things to clean up.

If the web interface is gone, that subpackage needs to be Obsoleted by something (probably the main package).

Spaces vs. tabs should be used consistently for indentation.  It looks like it is using tabs, for example in the BuildRequires, but you used spaces in your additions, so those should be convered to tabs.  You can also use rpmlint to check your SPEC file and it would complain about things like this.

Things that have been removed from the SPEC can be deleted instead of just commented out.  Thankfully we have SVN for history.

The %_create_ssl_certificate calls shouldn't be inside the if [ $1 = 1 ] block.

Fix those and I'll start by building it in Cauldron and see how that goes.  Thanks!

(In reply to David Walser from comment #39)
> If the web interface is gone, that subpackage needs to be Obsoleted by
> something (probably the main package).
I'm not really sure how to do that, because I never did before. I tried adding
"Obsoletes: freeradius-web"
 
> Spaces vs. tabs should be used consistently for indentation.  It looks like
> it is using tabs, for example in the BuildRequires, but you used spaces in
> your additions, so those should be convered to tabs.  You can also use
> rpmlint to check your SPEC file and it would complain about things like this.
OK, rpmlint now only warns for the hardcoded-library-path and the unversioned-explicit-obsoletes

> Things that have been removed from the SPEC can be deleted instead of just
> commented out.  Thankfully we have SVN for history.
Done!

> The %_create_ssl_certificate calls shouldn't be inside the if [ $1 = 1 ]
> block.
Moved, but I wonder if the [ $1 = 1 ] block is needed or if "openssl dhparam" could be called without that check

Created attachment 7308 [details]
draft-spec-file-freeradius-3.0.10

Attachment 7306 is obsolete: 0 => 1

Thanks!  I added the version on the obsoletes ( < 2.2.8-3 ), removed the subrel, enabled the wbclient BR (for Cauldron), and fixed a couple places where a bunch of lines ending with \ had a \ on the last line.

The [ $1 = 1 ] should be there, so that dh only gets created when the package is initially installed.  On upgrades, presumably the dh file will already be there.

I also had to fix some BRs:
BuildRequires:  hiredis-devel
BuildRequires:  iodbc-devel
BuildRequires:  json-c-devel
BuildRequires:  talloc-devel
BuildRequires:  ykclient-devel
BuildRequires:  yubikey-devel

Often putting lib at the beginning doesn't work as the 64-bit devel doesn't have that provides, but they'll both have a provides for it without the lib prefix.

I also had to BR openssl since it creates a dh file itself during the build process.

BOOTSTRAP raddb/certs/
gmake[1]: Entering directory '/home/iurt/rpmbuild/BUILDROOT/freeradius-3.0.10-1.mga6.i386/etc/raddb/certs'
openssl gendh -out dh -2 2048
gmake[1]: openssl: Command not found
Makefile:49: recipe for target 'dh' failed
gmake[1]: *** [dh] Error 127
gmake[1]: Leaving directory '/home/iurt/rpmbuild/BUILDROOT/freeradius-3.0.10-1.mga6.i386/etc/raddb/certs'
raddb/all.mk:117: recipe for target '/home/iurt/rpmbuild/BUILDROOT/freeradius-3.0.10-1.mga6.i386/etc/raddb/certs/ca.key' failed
make: *** [/home/iurt/rpmbuild/BUILDROOT/freeradius-3.0.10-1.mga6.i386/etc/raddb/certs/ca.key] Error 2

Maybe we don't need to create it again in %post?  If we do, it should be 2048 bits though, like they're doing here, so I did change that to 2048 in %post.

(In reply to David Walser from comment #44)
> Maybe we don't need to create it again in %post?  If we do, it should be
> 2048 bits though, like they're doing here, so I did change that to 2048 in
> %post.

Well, I guess the purpose of creating it in %post is that not everyone is using the same DH parameters.  There have been questions lately about whether that's a good idea.

I also had to add BR idn-devel for rlm_idn.

Thank you David for your help creating that spec file!
Do you think it makes sense to make that updated Version available on mga5, too? Ofcause by disabling wbclient due to samba 4 BR but maybe that way we will get a bigger testing community? Following the freeradius Readme.rst it is not recommended to use a v2 configuration with v3 Version. Instead it is advised to start with provided config defauls and add the local changes...

I'd rather get a real fix for the SSL thing so that won't happen again, especially since you have to re-do your whole config for the v3 update.  The v3 update would make sense if we have to and have no other option.

I would agree to that if there is a chance to get a fix quite soon. But according to comment 16 and comment 17 it looks not very good so far.
At the moment are all users who updated to last ssl security update not able to use their freeradius service as it fails on (re)start. Not everyone is able to do a local rebuild like Rod and I did. Until a fix is available I see no other option than doing a rebuild every time ssl is updated for Mageia users. Or do we simple live with the current situation?

We simply can't rebuild this every time OpenSSL needs an update.  We need to do something, but hopefully someone can come up with a simple fix for the existing package.  Just disabling/removing the SSL version check completely should do it.  Obviously we do need to fix this.

Hi,
As David, i think we can't let Mageia 5 in that situation with packages that stop working suddenly. We need a new version of freeradius without SSL version checking.

CC: (none) => richard

YES!!! I finally found a solution of our problem, and it is quite simple :)

MGA5 uses still freeradius version 2.2.8 which has a very old implementation of SSL version checking!!!

comment 15 from David and comment 16 from Rod are right and that is what was intended from the developpers "... --disable-openssl-version-check only disables the check for vulnerable versions of libssl, not the consistency checks. The patch counter of the libssl version can be incremented without triggering the error. This is the same as the checks OpenSSH does IIRC."

Source: freeradius devel list http://lists.freeradius.org/pipermail/freeradius-devel/2015-January/010434.html

But freeradius-server-2.2.8 has got two bugs
1. --disable-openssl-version-check COULD disable runtime checks which was fixed on 15th of October here https://github.com/FreeRADIUS/freeradius-server/commit/4f24d4cda8b43b5f703110b6f089759539b2e285#diff-371210f994ecc92a6dae4a0a9e6cf824

-> this means in theories setting that flag would help in version 2.2.8 but 

2. upstream bug (#1187) will prevent that because OpenSSL version check was not implemented correctly
https://github.com/FreeRADIUS/freeradius-server/pull/1187

The relevant lines of code can bee seen here:
https://github.com/FreeRADIUS/freeradius-server/pull/1187/files

In summary: we should update at least to freeradius-server-2.2.9 (that fixes bug #1187) or better move to last git version of 2.x.x series which fixes the --disable-openssl-version-check as well...

Any comments on that?

I'm all for updating to 2.2.9, but I'd rather not pull an entire git snapshot.  Could you find the commit that fixes the disable-openssl-version-check so that I can add that as a patch?

Since release of 2.2.9 there were 9 commits to git until today. Most of them regarding OpenSSL 1.0.2 and --disable-openssl-version-check
- Bump for 2.2.10
- Fix compatibility with OpenSSL 1.0.2
- note OpenSSL 1.0.2 idiocy
- Work around other OpenSSL stupidity
-  ENABLE_OPENSSL_VERSION_CHECK was intended to be used to disable checks for vulnerable OpenSSL versions, NOT our compile/runtime checks for OpenSSL version mismatches.
- Note recent changes
- Make default match config
- Fix build failure when --disable-openssl-version-check is set
- Merge pull request #1441 from TheMysteriousX/v2.x.x-fix-disable-ssl

(https://github.com/FreeRADIUS/freeradius-server/commits/v2.x.x)

I attach one patch for 2.2.9 release including six of the commits by excluding two (Bump for 2.2.10 and Note recent changes)

In detail
https://github.com/FreeRADIUS/freeradius-server/commit/a8d53ca3684c518216fac9d1dd3e6a9d2daf3639.patch 
https://github.com/FreeRADIUS/freeradius-server/commit/1a3ce7cd204bfd97bf8ccf1f665b6884cbfc0467.patch
https://github.com/FreeRADIUS/freeradius-server/commit/ffcd1143d43b43f5e28ed2fdcd8f924b79156624.patch
https://github.com/FreeRADIUS/freeradius-server/commit/4f24d4cda8b43b5f703110b6f089759539b2e285.patch
https://github.com/FreeRADIUS/freeradius-server/commit/b3af2547314f105107b3b6472e10288f21f0d4ac.patch
https://github.com/FreeRADIUS/freeradius-server/commit/5c23709fc90bb30b51c598aa81a05d4fe0d8cf70.patch

Created attachment 7312 [details]
backported-fixes-from-upstream-git-to-2.2.9-release

Thanks Stefan!  Great job.

Testing procedure is in Bug 8726.

Advisory:
----------------------------------------

The freeradius package has been updated to the most current code in the
upstream 2.2.x branch, including updating to 2.2.9 and including additional
OpenSSL-related bug fixes.

This update should allow it to work more reliably with OpenSSL 1.0.2 and with
future OpenSSL security updates.

References:
http://lists.freeradius.org/pipermail/freeradius-users/2015-September/080119.html
https://github.com/FreeRADIUS/freeradius-server/commits/v2.x.x
----------------------------------------

Updated packages in core/updates_testing:
----------------------------------------
freeradius-2.2.9-1.mga5
freeradius-krb5-2.2.9-1.mga5
freeradius-ldap-2.2.9-1.mga5
freeradius-postgresql-2.2.9-1.mga5
freeradius-mysql-2.2.9-1.mga5
freeradius-unixODBC-2.2.9-1.mga5
freeradius-sqlite-2.2.9-1.mga5
freeradius-yubikey-2.2.9-1.mga5
libfreeradius1-2.2.9-1.mga5
libfreeradius-devel-2.2.9-1.mga5
freeradius-web-2.2.9-1.mga5

from freeradius-2.2.9-1.mga5.src.rpm

Whiteboard: (none) => has_procedure
Assignee: pkg-bugs => qa-bugs

Great job.
It's ok for me.
My N.A.C. (captive portal) powered with mageia 5 is working fine now.
Thx

(In reply to rexy from comment #57)
> Great job.
> It's ok for me.
> My N.A.C. (captive portal) powered with mageia 5 is working fine now.
> Thx

Which architecture?

We're the developers of ALCASAR project (www.alcasar.net) based on Mageia.
Architecture :
- system : Mageia 4.1 (migration to mageia 5 in progress)
- authentication : freeradius + coova-chilli + mariadb
- filtering : dnsmasq + dansguardian + ipt-netflow + rrd + HAVP + clamav
- web admin : apache + openssl + php

# cat /etc/release
Mageia release 5 (Official) for i586
# rpm -qa freeradius
freeradius-2.2.9-1.mga5
# echo 'testing Cleartext-Password := "password"' >> /etc/raddb/users
# systemctl restart radiusd.service
# radtest testing password 127.0.0.1 0 testing123
Sending Access-Request of id 21 to 127.0.0.1 port 1812
        User-Name = "testing"
        User-Password = "password"
        NAS-IP-Address = 192.168.39.2
        NAS-Port = 0
        Message-Authenticator = 0x00000000000000000000000000000000
rad_recv: Access-Accept packet from host 127.0.0.1 port 1812, id=21, length=20
#

Works fine on my system. MGA5-32

@rexy
32-bit or 64bit?

64b

This can be validated now.  Thanks everyone.

Whiteboard: has_procedure MGA5-32-OK M => has_procedure MGA5-32-OK MGA5-64-OK

This update is now validated

The advisory in comment #56 needs to be uploaded to SVN

The packages can then be pushed to updates

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update

An update for this issue has been pushed to Mageia Updates repository.

http://advisories.mageia.org/MGAA-2016-0001.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED