There aren't massive security holes in other libraries. I'm not sure if other projects are doing this. I know for my sanity, I don't want people blaming FreeRADIUS because they've chosen to use a vulnerable version of OpenSSL.
Which will happen if FR doesn't check for "bad" versions of OpenSSL.
OpenSSL is used by a lot of modules and different components of the server. Even with the patches to the EAP module, FreeRADIUS is still vulnerable to malicious SQL servers (PG and MySql), LDAP servers, and HTTP servers. That's why the checks have been left in the code, even though the main attack vector will be close with 2.2.5/3.0.3.
I think you guys already do more than enough - way more than most projects - to provide long-term stable releases. I don't think you need to do more, and I certainly don't think you need to be cleaning up OpenSSL's mess. That way lies moral hazard!
Hopefully if other projects follow suit, it'll shame the libssl guys into competent development practices. They are not taking advantage of code quality tools freely available to them, that's either arrogance or incompetence. Distros should disable the check by requiring versions of dependencies which have already been patched, and patching the default config files appropriately. Users which are not using a package management system are the ones most at risk, and they are the ones most likely to see the error messages. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2