From owner-freebsd-security@FreeBSD.ORG Wed Apr 9 21:38:11 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B3E94BC4 for ; Wed, 9 Apr 2014 21:38:11 +0000 (UTC) Received: from mail-out.apple.com (crispin.apple.com [17.151.62.50]) (using TLSv1 with cipher DES-CBC3-SHA (168/168 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 97F721449 for ; Wed, 9 Apr 2014 21:38:11 +0000 (UTC) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0N3S00G5J6EJEW10@mail-out.apple.com> for freebsd-security@freebsd.org; Wed, 09 Apr 2014 13:33:40 -0700 (PDT) X-AuditID: 11807157-f79aa6d0000017b2-6e-5345aea3ec57 Received: from [17.149.225.221] (Unknown_Domain [17.149.225.221]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 04.CF.06066.4AEA5435; Wed, 9 Apr 2014 13:33:40 -0700 (PDT) Subject: Re: Proposal From: Charles Swiger In-reply-to: Date: Wed, 09 Apr 2014 13:33:39 -0700 Message-id: References: <9eeba1ab-2ab0-4188-82aa-686c5573a5db@me.com> <8D81F198-36A7-47F4-B486-DA059910A6B4@spam.lifeforms.nl> <867g6y1kfe.fsf@nine.des.no> To: Nathan Dorfman X-Mailer: Apple Mail (2.1510) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrALMWRmVeSWpSXmKPExsUiOPXhXd0l61yDDbZ+57Xo2fSEzWL6qXgH Jo8Zn+azeDw9M4clgCmKyyYlNSezLLVI3y6BK2PNnSvMBVuFKg7c/8rUwPier4uRk0NCwETi 04bPjBC2mMSFe+vZuhi5OIQE+pkknuyawwKSYBbQkrjx7yVTFyMHB6+AnsT2X3IgYWEBUYnL G74zgoTZBNQkJkzkAQlzCgRKXPh+iBnEZhFQkWg/2M8GMcVL4tHjiYwQtrbEsoWvwWp4Bawk 3j3cxQ6x9gqjxI47y8HWiggoSGx9+50V4jZZidPnnrNMYOSfheSiWQgXzUIydgEj8ypGgaLU nMRKE73EgoKcVL3k/NxNjKBwaygM38H4b5nVIUYBDkYlHt4Dy1yDhVgTy4orcw8xSnAwK4nw rlwFFOJNSaysSi3Kjy8qzUktPsQozcGiJM7bPQkoJZCeWJKanZpakFoEk2Xi4JRqYDzw3O7g j3LJ9hUV+p01sUsa7FNOzLy8efOST1Idj1vrj85eHtpU91u++6CElqTyrl/TTKPWcP7juLWw pr2oryHww0tOnYgLmydPCBOqeb/n+Zqym0d3zdFw8zk67Zxx1oyfPXq9s8Ul16myPb/4fF9r d6+wU6/ISrPlq3a98Hwav0n4y73Z+qJKLMUZiYZazEXFiQAyR1bUMwIAAA== Cc: "freebsd-security@freebsd.org security" X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Apr 2014 21:38:11 -0000 Hi-- On Apr 9, 2014, at 12:44 PM, Nathan Dorfman 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