# radiusd -X (...) libssl version mismatch. Built with: 1000107f Linked: 1000108f Is this something portage should be able to fix? Recompile freeradius after libssl upgrade or something? Reproducible: Always
(In reply to Kobboi from comment #0) > # radiusd -X > (...) > libssl version mismatch. Built with: 1000107f Linked: 1000108f > > Is this something portage should be able to fix? Recompile freeradius after > libssl upgrade or something? Maybe it should check for features, not versions.
I have similar experience. Every time openssl has a (minor) upgrade, freeradius has to be rebuilt against the new library. While this may be an upstream issue with freeradius, perhaps we can (at least temporarily) add a dependancy to rebuild freeradius with the updated openssl? Otherwise it fails the next time radiusd is restarted, usually on a system reboot at a later date.
(In reply to David K. Thompson from comment #2) > While this may be an upstream issue with freeradius, perhaps we can (at > least temporarily) add a dependancy to rebuild freeradius with the updated > openssl? If dev-libs/openssl would set a sub-SLOT, then this could be done easily. But as is, we should probably rip out or cripple the offending code in freeradius. :)
(In reply to Jeroen Roovers from comment #3) > (In reply to David K. Thompson from comment #2) > > While this may be an upstream issue with freeradius, perhaps we can (at > > least temporarily) add a dependancy to rebuild freeradius with the updated > > openssl? > > If dev-libs/openssl would set a sub-SLOT, then this could be done easily. > But as is, we should probably rip out or cripple the offending code in > freeradius. :) Perhaps a patch to make the version mismatch a prominent WARNING vs. a fatal error? (as with net-ftp/proftpd)
(In reply to David K. Thompson from comment #4) > (In reply to Jeroen Roovers from comment #3) > > (In reply to David K. Thompson from comment #2) > > > While this may be an upstream issue with freeradius, perhaps we can (at > > > least temporarily) add a dependancy to rebuild freeradius with the updated > > > openssl? > > > > If dev-libs/openssl would set a sub-SLOT, then this could be done easily. > > But as is, we should probably rip out or cripple the offending code in > > freeradius. :) > > Perhaps a patch to make the version mismatch a prominent WARNING vs. a fatal > error? (as with net-ftp/proftpd) Patch below. It checks below for vulnerable versions anyway and will still exit as it should in those cases: Elsewhere the comment "better to die now than segfault later". I dont agree, especially when these are for minor openssl version upgrades. --- src/main/version-orig.c 2015-01-22 12:37:38.000000000 -0800 +++ src/main/version.c 2015-01-22 12:36:14.000000000 -0800 @@ -59,8 +59,8 @@ " Built with: %lx\n Linked: %lx", (unsigned long) ssl_built, (unsigned long) ssl_linked); - - return -1; +/* Warn only. Give the user the opportunity to rebuild when upgrading OpenSSL */ +/* return -1; */ }; if (!allow_vulnerable) {
Created attachment 394658 [details, diff] Patch to remove fatal exit for SSL version mismatch
(In reply to David K. Thompson from comment #6) > Created attachment 394658 [details, diff] [details, diff] > Patch to remove fatal exit for SSL version mismatch Above comments notwithstanding, if there are versions which are known to cause stability problems other than the specifically vulnerable versions already tested there may be a good case for refusing to start. A minor version mismatch is a rather large cannon for this mosquito. Perhaps someone upstream can add a more discriminating check? :)
Can we just add openssl:= while waiting for the upstream? I hit this bug (again) yesterday. It took me awhile to figure out what's wrong and then I found that the bug is known for a year.
CCing openssl maintainers, but I disagree with freeradious upstream requiring this rebuild on every bump :/
freeradius is broken. the openssl abi is compatible across minor versions. just delete the check altogether. openssl changes SONAME when it's not compatible.
version 2.2.9 has --disable-openssl-version-check option which might fix the problem.
(In reply to Anton Bolshakov from comment #11) > version 2.2.9 has --disable-openssl-version-check option which might fix the > problem. It worked for me with 3.0.11-r1
Great. echo "net-dialup/freeradius freeradius.conf" >> /etc/portage/package.env mkdir -p /etc/portage/env echo "EXTRA_ECONF=\"--disable-openssl-version-check\"" > /etc/portage/env/freeradius.conf Works for me with 2.2.5
(In reply to David K. Thompson from comment #13) > Great. > > echo "net-dialup/freeradius freeradius.conf" >> /etc/portage/package.env > mkdir -p /etc/portage/env > echo "EXTRA_ECONF=\"--disable-openssl-version-check\"" > > /etc/portage/env/freeradius.conf > > Works for me with 2.2.5 Except that it doesnt. That was tested with 2.2.9, not 2.2.5 (current stable version) Freeradius has fixed the version check as of 2.2.9 so there's no need to disable the check to avoid this bug. If you disable it, you also lose the check for vulnerable versions of openssl which is not desirable. http://lists.freeradius.org/pipermail/freeradius-devel/2015-January/010417.html Perhaps we can make 2.2.9 stable, and/or patch 2.2.5 ?
2.2.9-r1 is in stable now
