From owner-freebsd-security@FreeBSD.ORG Fri Apr 25 06:55:40 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6839CD36; Fri, 25 Apr 2014 06:55:40 +0000 (UTC) Received: from acme.spoerlein.net (unknown [IPv6:2a02:2528:fa:1000::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.spoerlein.net", Issuer "CAcert Class 3 Root" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E8B1D1673; Fri, 25 Apr 2014 06:55:39 +0000 (UTC) Received: from localhost (acme.spoerlein.net [IPv6:2a02:2528:fa:1000::1]) by acme.spoerlein.net (8.14.8/8.14.7) with ESMTP id s3P6tSPK092035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 25 Apr 2014 08:55:29 +0200 (CEST) (envelope-from uqs@FreeBSD.org) Date: Fri, 25 Apr 2014 08:55:28 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= To: Erik Cederstrand , Li-Wen Hsu Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425065528.GE3620@acme.spoerlein.net> References: <23494.1398337629@server1.tristatelogic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Mailman-Approved-At: Fri, 25 Apr 2014 12:07:56 +0000 Cc: "freebsd-security@freebsd.org" , "Ronald F. Guilmette" 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: Fri, 25 Apr 2014 06:55:40 -0000 +lwhsu Things are in motion to bring back the scan-build results on FreeBSD infrastructure, so that it doesn't disappear without notice, again. On Thu, 2014-04-24 at 13:57:13 +0200, Erik Cederstrand wrote: > Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette : > > > > 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''? > > > > int x = -1; > > > > 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 α-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