From owner-freebsd-security@FreeBSD.ORG Thu Apr 24 12:10:16 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 6FFEB9D6 for ; Thu, 24 Apr 2014 12:10:16 +0000 (UTC) Received: from outgoing.tristatelogic.com (segfault.tristatelogic.com [69.62.255.118]) by mx1.freebsd.org (Postfix) with ESMTP id 4DD8810B7 for ; Thu, 24 Apr 2014 12:10:15 +0000 (UTC) Received: from segfault-nmh-helo.tristatelogic.com (localhost [127.0.0.1]) by segfault.tristatelogic.com (Postfix) with ESMTP id 4FFD83AE6E for ; Thu, 24 Apr 2014 05:10:12 -0700 (PDT) From: "Ronald F. Guilmette" To: "freebsd-security@freebsd.org" Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? In-Reply-To: <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk> Date: Thu, 24 Apr 2014 05:10:12 -0700 Message-ID: <23889.1398341412@server1.tristatelogic.com> 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 12:10:16 -0000 In message <546CE3A8-FC87-472F-8A63-0497D0D28789@cederstrand.dk>, Erik Cederstrand wrote: >I don't disagree with you, but rewriting 1000 if-else cases in single-threaded >userland programs just so the analyzer understands them is 1) tedious and 2) >bound to accidentally introduce at least 50 new bugs I feel compelled to point out that one could make the exact same two assertions about writing code _generally_, i.e. writing software AT ALL is (1) tedious and (2) bound to accidentally introduce at least 50 new bugs. I feel further compelled to point out that at least the first of those two assertions also applies, in my experience, to writing QUALITY code. That doesn't mean it shouldn't be done. And anyway, who said anything about userland? I personally would contend that if the folks writing kernel code are failing to eliminate compile time warnings, then that is also a travesty, and perhaps even moreso than in the case of userland code. Certainly, if a developer misses a bug because he failed to pay any attention to the flashing yellow lights, then that is likely to have far more serious ramifications if the code in question is within the kernel. >...since most real-life examples >are considerably more complicated than the minimal example I posted. If in fact, as you assert, ``most'' real-life examples of contexts and situations where it is tedious and/or difficult to eliminate non-useful compile-time warnings are ``complicated'' then I would guess that it would be easy for you to find just _one_ such ``real life'' difficult example and post it here. Please do. In my personal estimation no such alleged ``complicated'' real life examples actually exist. But I am more than willing to be proven wrong. Regards, rfg