From owner-freebsd-security@FreeBSD.ORG Sat Apr 26 06:40:20 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 7C6209F2 for ; Sat, 26 Apr 2014 06:40:20 +0000 (UTC) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3DCB51991 for ; Sat, 26 Apr 2014 06:40:20 +0000 (UTC) Received: by mail-qc0-f175.google.com with SMTP id e16so5039104qcx.34 for ; Fri, 25 Apr 2014 23:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=bc2yj6i8BsqJDiIqtJeUjNekQOoX6IgJnOxfGt0CWIc=; b=NOu6VrzwWb7vG/Rcc7W7UyjwwWx4z75gjNA+8Lar2Lh/3URfHR4MXrBYzY689lB8pK 7iqt3h7RzZgxCqRpWqtG9EgQLZU/5QxV0ZYT1cvx+gISZ+w4DN/RF2RA8y4Tv1iG2X1z WLsNI1jQ4zIZuBY11XSPtNr7v5IwhNL/sPAKBT4eJp+395Ie4imCCEBiQ41kVOo0nD5p RCFlwWBQ++cX4UDXJV1aco/SPCL1d3pmLxqwXQp46XjtAdznQjcSstJWlQ6mzFOaHeq1 Tx0cAiKgcXk3dOUEQCZ4HZE9395+kc58274L1Ffir02Zd6sCNo9HpQ2Q3wZ5PTzCESMv uxPg== MIME-Version: 1.0 X-Received: by 10.224.66.133 with SMTP id n5mr17515241qai.11.1398494418777; Fri, 25 Apr 2014 23:40:18 -0700 (PDT) Sender: benlaurie@gmail.com Received: by 10.96.162.196 with HTTP; Fri, 25 Apr 2014 23:40:18 -0700 (PDT) In-Reply-To: <32377.1398460907@server1.tristatelogic.com> References: <32377.1398460907@server1.tristatelogic.com> Date: Sat, 26 Apr 2014 07:40:18 +0100 X-Google-Sender-Auth: pkh3tPeGDjGfU6e1irfYvSU0tyQ Message-ID: Subject: Re: OpenSSL static analysis, was: De Raadt + FBSD + OpenSSH + hole? From: Ben Laurie To: "Ronald F. Guilmette" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-security@freebsd.org security" 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: Sat, 26 Apr 2014 06:40:20 -0000 On 25 April 2014 22:21, Ronald F. Guilmette wrote: > > In message > Ben Laurie wrote: > >>But that would then hide the error condition of it being not set to a >>new value after initialisation. > > The (modified/quieted) code example under discussion is as follows: > > variable = value0; /* initialization */ > if (condition) variable = value1; > if (!condition) variable = value2; > use (variable); > > Please note that variable *is* *always* set to some value (either value1 > or value2) after initialization. The "error condition" that you seem > concerned about having explicitly flagged does not in fact exist in the > example code snippet under discussion. Of course it doesn't, that's the whole point. >>One better answer would be to have a way to annotate that after the >>two conditionals you assert that |variable| is initialised. Then a >>future, smarter static analyzer can attempt to prove you wrong. > > Sir, is there any sense in which the final line of the above example > _does not_ already and standing all by itself constitute an implicit > assertion that "variable" has been initialized by that point in the > code? My point is that if you want to silence the warning, the right way to do it is by saying "you are wrong, here is my claimed truth" rather than by changing the code to avoid the shortcoming in analysis. The reason being that future analysis can decide to ignore or disprove your assertion, but cannot ignore the suppression you suggest.