Date: Wed, 09 Apr 2014 13:33:39 -0700 From: Charles Swiger <cswiger@mac.com> To: Nathan Dorfman <na@rtfm.net> Cc: "freebsd-security@freebsd.org security" <freebsd-security@freebsd.org> Subject: Re: Proposal Message-ID: <BAA8849A-4EEE-476D-B2F8-F79E135D25F4@mac.com> In-Reply-To: <CADgEyUstkxO1i_B9Qsw=K9qT=nrh9evhv8VekMdNKauOQFN6dg@mail.gmail.com> References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> <CADgEyUstkxO1i_B9Qsw=K9qT=nrh9evhv8VekMdNKauOQFN6dg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi-- On Apr 9, 2014, at 12:44 PM, Nathan Dorfman <na@rtfm.net> wrote: > 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? Sure, it's plausible. In fact, that exact workaround already was posted: http://www.openssl.org/news/secadv_20140407.txt "Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS." > Given the severity of the issue, it doesn't seem that an immediate > advisory stating "here's an immediate workaround, a full fix will be > coming in the next day or two" would be terribly inappropriate. > Perhaps this workaround would have required more testing than I > imagine, but surely it'd be a tiny fraction of the time required to > release the full fix? Your choices are simple: you can either do whatever you like yourself, in which case the time required to test things to your satisfaction is entirely up to you. Or you can wait until your OS vendor completes the release engineering needed to build, deploy, and validate the fixes, then publish the updated versions. > While I'm out here drawing fire, I might as well also ask if I'm crazy > to think that it might be a good idea for the base system OpenSSL (and > other third party imports) to just disable any and all non-essential > functionality that can be disabled at compile time? Deploying software with the default options selected is generally the most reasonable approach. Under unusual situations, disabling default functionality might be reasonable, but that generally indicates something is broken with the choices made upstream by the software authors. > Non-essential meaning everything not required for the base system to function -- > there's always the ports version if anyone needs more. Disabling commonly used functionality means that a lot more folks would need to replace the base system version with the ports version. Taken to the extreme, the result would be to effectively make the base system version useless. Regards, -- -Chuck
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BAA8849A-4EEE-476D-B2F8-F79E135D25F4>