On 13 Jan 2015, at 15:31, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On 8 Jan 2015, at 20:41, Alan DeKok <aland@deployingradius.com> wrote:
On Jan 7, 2015, at 8:16 PM, Michael Richardson <mcr@sandelman.ca> wrote:
It's hard if you also have other things which want *different* versions of OpenSSL... really, if they shared libraries are not compatible, the .so files should have their version number bumped, but I know that this is hard for some distros.
OpenSSL has a wonderful habit of making header files for (e.g.) 1.0.1 incompatible with the binaries for 1.0.2. As a result, upgrades can cause your application to crash.
FreeRADIUS runs into this more than most applications. Most applications just use the SSL_read() and SSL_write() APIs to deal with TCP connections. So they don’t need to get into the internals of SSL behaviour. FreeRADIUS has to extract SSL from EAP, and in turn RADIUS. So it has to do unusual (but allegedly legal) things with OpenSSL.
The OpenSSL APIs lie to you. They say you can do something, which is true. What they *don’t* say is that they change in random incompatible ways at a moments notice.
I gave up on APR years ago for similar reasons.
A fix for this was contributed by Philippe Wooding, who doesn't read the lists but deserves recognition anyway :).
It's due to the OpenSSL libraries on RHEL and its variants having multiple versions of the SSLeay() symbol (the function used to retrieve the OpenSSL version).
If OpenSSL was only transitively linked to the binary calling SSLeay() the wrong version was used. Linking libfreeradius-server directly against libssl seems to have fixed the problem.
To clarify that was for the OP's original question, not the largely pointless discussion on static linking that followed. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2