On 8 Apr 2014, at 16:52, <stefan.paetow@diamond.ac.uk> <stefan.paetow@diamond.ac.uk> wrote:
Please don't do that, for the exact reasons you outlined.
Hardcoding a version number blacklist into the build environment just means everyone building against an enterprise distro will have to patch your changes out.
I realise it's a serious vulnerability, but "configure.in" of a project using the library is not the right place to address this.
You'd be better off adding a runtime check and refusing to start without "allow_unsafe_openssl" global set or similar, if you must. At least that way people can configure the server to start once they've patched.
Response from Fedora project was:
"I took the approach of least resistance, which was to patch the bug. The OpenSSL maintainers have whatever reason they have to keeping OpenSSL at 1.0.1e and it wasn't my place to change that. It also happens to be the approach that RHEL took."
There we have it. Path of least bleating and most expediency.
*sigh*. Well thanks for checking anyway. To be fair OpenSSL don't seem to be taking security seriously, this should have been caught by static analysis... except that code only gets submitted to Coverity sporadically, and they don't like using it because of the high rate of false positives. You know what causes high rates of false positives? Weird fucked up code... Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2