Date: Fri, 25 Apr 2014 08:55:28 +0200 From: Ulrich =?utf-8?B?U3DDtnJsZWlu?= <uqs@FreeBSD.org> To: Erik Cederstrand <erik@cederstrand.dk>, Li-Wen Hsu <lwhsu@freebsd.org> Cc: "freebsd-security@freebsd.org" <freebsd-security@freebsd.org>, "Ronald F. Guilmette" <rfg@tristatelogic.com> Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? Message-ID: <20140425065528.GE3620@acme.spoerlein.net> In-Reply-To: <D18165F1-0213-4A1F-96F4-6E0F6F735C69@cederstrand.dk> References: <23494.1398337629@server1.tristatelogic.com> <D18165F1-0213-4A1F-96F4-6E0F6F735C69@cederstrand.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
+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 <rfg@tristatelogic.com>: > > > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140425065528.GE3620>