From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 11:59:52 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 EC6D1528 for ; Thu, 24 Apr 2014 11:59:52 +0000 (UTC) Received: from csmtp3.one.com (csmtp3.one.com [91.198.169.23]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ADA8C1E59 for ; Thu, 24 Apr 2014 11:59:52 +0000 (UTC) Received: from [192.168.187.70] (unknown [87.54.33.251]) by csmtp3.one.com (Postfix) with ESMTPA id 62590400134FD for ; Thu, 24 Apr 2014 11:59:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Erik Cederstrand In-Reply-To: <23494.1398337629@server1.tristatelogic.com> Date: Thu, 24 Apr 2014 13:59:10 +0200 Cc: "freebsd-security@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> References: <23494.1398337629@server1.tristatelogic.com> X-Mailer: Apple Mail (2.1874) 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: Thu, 24 Apr 2014 11:59:53 -0000 Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette = : >=20 > In the post that you are replying to, I took issue with two prior = assertions > made by Mark Andrews, specifically (1) that some clang static analysis > warnings are "false positives" and (2) that elimination some of them = was > "impossible". I really wish the reports were online again so we weren't discussing = hypothetical situations here. Ulrich? > Sir, does not the following trivial and obvious single line = modification > to the above code eliminate the warning? And does it not do so = *without* > the need for ``considerable effort''? >=20 > int x =3D -1; >=20 > I thank you for providing me with the example above, and thus also = this > opportunity to so perfectly illustrate my fundamental point. The example I gave is of course trivial to rewrite. It was the shortest = possible example I could think of to illustrate the situation. It was = condensed from a really convoluted if-else case which was not incorrect = but quite difficult to untangle. And yes, it's laudable to rewrite it = for the sake of readability, but it doesn't fix any security issues. > As the examples above illustrate, the claim that eliminating the = non-helpful > warnings is ``too hard'' cannot, I believe, be supported by the facts, = and > the (unfortunately widespread) perception that eliminating such = warnings is > ``too hard'' is actually... and not to put too fine a point on it... a > product more of ignorance or laziness than it is a product of genuine > difficulty in quieting the unhelpful diagnostics in question. As others have pointed out, 'too hard' can also mean 'too hard' to get = someone with commit access to actually commit the patch and accept the = risk of introducing new bugs. Case in point: I contributed this = one-liner patch for ZFS found by Clang Analyzer, adding the __noreturn__ = pragma you also mention: https://www.illumos.org/issues/3363. For 1,5 = years, I have been unable to get anyone from FreeBSD or Illumos to = commit it or even review it. My personal conclusion is that patches to = warnings have to fix more severe issues to get attention. Or in other = words, if the warning is a result of the compiler or analyzer being too = stupid, the response will more likely be "fix the analyzer", and = compiler warnings are more likely to be ignored. > I'm sorry, you are apparently using some domain-specific terminology = with > which I am not familiar. What exactly is "IPA" and "alpha-remaning"? = Do > these have something do do with SSL? Alpha renaming, or =CE=B1-conversion, is explained here: = http://en.wikipedia.org/wiki/Lambda_calculus IPA, or Inter-Procedural Analysis, is explained here: = http://llvm.org/docs/Lexicon.html Erik=