Date: Thu, 24 Apr 2014 13:59:10 +0200 From: Erik Cederstrand <erik+lists@cederstrand.dk> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org> Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <697C2D01-D8F7-4BC4-BBED-6B4A93105E62@cederstrand.dk> In-Reply-To: <23494.1398337629@server1.tristatelogic.com> References: <23494.1398337629@server1.tristatelogic.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Den 24/04/2014 kl. 13.07 skrev Ronald F. Guilmette = <rfg@tristatelogic.com>: >=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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?697C2D01-D8F7-4BC4-BBED-6B4A93105E62>