On Wed, Apr 9, 2014 at 4:12 PM, Dag-Erling Smørgrav <d...@des.no> wrote: > Nathan Dorfman <n...@rtfm.net> writes: >> Is it implausible to suggest that before embarking on the task of >> backporting, reviewing, testing and releasing the actual fix, an >> announcement could have been made immediately with the much simpler >> workaround of adding -DOPENSSL_NO_HEARTBEATS to the OpenSSL compiler >> flags? > > No, that's not implausible, although I don't know whether that > workaround was known at the time. It seems obvious in retrospect, but > may not have been that obvious under pressure. Was it mentioned in the > OpenSSL advisory?
Yeah, I should have been clearer -- I personally learned about that from the OpenSSL advisory itself, which states: Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS. https://www.openssl.org/news/secadv_20140407.txt Be that as it may, Xin's explanation that simply committing a change to the Makefile would be ineffective in the face of a -DNO_CLEAN build makes sense. I didn't think about that. Moving on, is it not worth talking about going in and defining every -DOPENSSL_NO_* flag that exists and doesn't break the base system? On the simple grounds that there appears to be little to be gained from this kind of feeping creaturism, and plenty, as it turns out, to be lost. Of course, maybe the resulting build won't even work, or at least not work without significant effort. So this is more of a question than an actual suggestion. -nd. _______________________________________________ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
