Arran Cudbard-Bell <a.cudbardb@freeradius.org> on Tue, 2014/06/17 08:31:

On 17 Jun 2014, at 07:12, Christian Hesse <list@eworm.de> wrote:

...

From: Christian Hesse <mail@eworm.de>

Even if dynamic linking is just fine, radiusd fails after ever openssl update. (Distribution toolkits do not detect this, so distribution packages break on a regular basis.) This changes behavior so that it still fails on library downgrade, but just warns if openssl library has been upgraded.

The point of adding the check, was because even minor versions of libssl had changes which broke ABI compatibility.

I'm not sure how your suggestion helps? If there's any change in libssl version it could cause ABI incompatibility, it doesn't matter if it's an upgrade or downgrade.

I had thought this is to fetch cases where libssl version changes and introduces any (possibly old) security vulnerabilities. In theory ABI should stay compatible with minor updates. And major updates should break if dynamic linking breaks. Or did that happen when system toolchain (gcc and friends) was updated? Still the question is whether freeradius should break on ABI incompatibility change (which should still give a warning with my patch) or break on *every* openssl update, regardless of whether or not ABI changed. Searching for "freeradius libssl version mismatch" gives a lot of matches, so looks like this is a real issue. -- main(a){char*c=/* Schoene Gruesse */"B?IJj;MEH" "CX:;",b;for(a/* Chris get my mail address: */=0;b=c[a++];) putchar(b-1/(/* gcc -o sig sig.c && ./sig */b/42*2-3)*42);}

On Tue, Jun 17, 2014 at 4:10 PM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:

On 17 Jun 2014, at 08:43, Christian Hesse <list@eworm.de> wrote:

...

Still the question is whether freeradius should break on ABI incompatibility change (which should still give a warning with my patch) or break on *every* openssl update, regardless of whether or not ABI changed.

Searching for "freeradius libssl version mismatch" gives a lot of matches, so looks like this is a real issue.

Some of those aren't for FreeRADIUS.

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=732940

OpenSSH has also adopted this approach, with a very similar message to us. Obviously they got annoyed too.

I've changed the behaviour to match theirs.

... and apparently Debian's "solution" to the problem (from the same page) is * Restore patch to disable OpenSSL version check (closes: #732940). So FR's position is to leave it to official distro packagers to disable it as well, just like allow_vulnerable_openssl? -- Fajar

On 17 Jun 2014, at 10:36, Phil Mayers <p.mayers@imperial.ac.uk> wrote:

I can see why Debian do that tbh if they feel soname is now reliable for ossl.

Rather than every package carrying a brittle diff to disable this, perhaps there should be a ./configure check to disable the SSL checks?

I'm not seeing what the issue is. FreeRADIUS will now only refuse to start if the Major or Minor version of libssl differs. The complaints on the interwebs are about the patch version changing, which is fair enough, we probably don't need to be *that* strict. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2

Let's say the OpenSSL guys get really clued up all of a sudden, and/or LibreSSL takes off. Assume that the ABI via the .soname becomes really solid, but the version number starts to increment rapidly. Not impossible. I shouldn't have to re-compile FreeRADIUS to take advantage of that.

I suspect that Arran et al will cross that bridge when we get to it? Stefan Janet(UK) is a trading name of Jisc Collections and Janet Limited, a not-for-profit company which is registered in England under No. 2881024 and whose Registered Office is at Lumen House, Library Avenue, Harwell Oxford, Didcot, Oxfordshire. OX11 0SG. VAT No. 614944238

Hi, On Tue, Jun 17, 2014 at 11:39:25AM +0100, Arran Cudbard-Bell wrote:

On 17 Jun 2014, at 11:01, Phil Mayers <p.mayers@IMPERIAL.AC.UK> wrote:

...

I don't think applications should be enforcing this, full stop. I don't expect you'll agree with me, but never mind.

No, I don't agree. Developer time is a finite resource. I don't want our time wasted helping people debug issues caused by libssl compatibility issues.

In a perfect world, I'm with Phil on this one. But as things stand at present, it's a grey area. Checks cause problems, such as distros having to remember to recompile FR when new libraries come out - this would be a right pain if all software did this for all libraries, and mostly defeat a large point of shared libraries. The check for heartbeat openssl bug is a case in point; different distros have crazy policies on library version numbers, which means the check is rather annoying unless you build yourself. This then causes other support issues ("my package won't install, I followed all the right build instructions, what's wrong?"). So it's support problems caused by incompatible libraries, or by things that stop the server running. I think I'd go the middle ground - a very large fat warning at the bottom of the start up debug output and in the main log file, but still run. Something along the lines of ********************************************************************** * WARNING! Some library versions may not be compatible with this * * version of FreeRADIUS. If you have problems or crashes, * * please recompile against the current versions or contact * * your distribution for support. * * * * OpenSSL is version 1.0.4, compiled against 1.0.2 * * * ********************************************************************** The crash handler should probably print out the same warning. Then the questions on the mailing lists should appear more when there are real problems, rather than the drip of "my FR won't start, helpz!" with the blunt cookie-cut answers that inevitably arise. Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>

On 17/06/14 14:36, Alan DeKok wrote:

Phil Mayers wrote:

...

OpenSSL has broken ABI in the past without a .soname bump. Very annoying. That does not make it your business to hard-code a version number into the application IMO.

It means that people complain *here* when OpenSSL breaks things. That's annoying. I'd rather have FreeRADIUS produce a useful error message, telling them where the real problem is.

On reflection I guess I can see the difference - a segfault due to ABI mismatch isn't obvious. It's *not* clear to me that it will reduce hassles on the mailing list - I have a fear there will end up being loads of deployed versions of the server with the check, and we'll be swamped by people asking how to fix it but refusing to recompile (we know this is a "thing"). But maybe it being obvious will make that ok.

I'm OK with adding a configuration directive which tells the server to ignore this check. But the check MUST be there by default, and MUST be enabled by default.

Fair enough. I would like to not have to rebuild the server in the event the version number changes but ABI does not. I have no big problem doing this in the config, or the server warning noisily when it starts or crashes.