From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS22989 209.51.188.0/24 X-Spam-Status: No, score=-3.6 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 3AAFE1F45F for ; Fri, 10 May 2019 11:51:07 +0000 (UTC) Received: from localhost ([127.0.0.1]:41790 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP43N-0005zC-Kn for normalperson@yhbt.net; Fri, 10 May 2019 07:51:05 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hP43H-0005z2-Sy for bug-gnulib@gnu.org; Fri, 10 May 2019 07:51:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hP43G-000502-N7 for bug-gnulib@gnu.org; Fri, 10 May 2019 07:50:59 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59042) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hP43G-0004zX-Gt for bug-gnulib@gnu.org; Fri, 10 May 2019 07:50:58 -0400 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A0D0F3082137; Fri, 10 May 2019 11:50:57 +0000 (UTC) Received: from kdudka-nb.localnet (unknown [10.43.2.82]) by smtp.corp.redhat.com (Postfix) with ESMTP id F1E7C60CAB; Fri, 10 May 2019 11:50:56 +0000 (UTC) From: Kamil Dudka To: Florian Weimer Subject: Re: Coverity false positives triggered by gnulib's implementation of base64 Date: Fri, 10 May 2019 13:51:07 +0200 Message-ID: <2533140.GjjxmHaaLF@kdudka-nb> In-Reply-To: <87mujupmow.fsf@oldenburg2.str.redhat.com> References: <2475310.f135Qeco9B@kdudka-nb> <29387202.mYf3tFGfHq@kdudka-nb> <87mujupmow.fsf@oldenburg2.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.42]); Fri, 10 May 2019 11:50:57 +0000 (UTC) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.132.183.28 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Paul Eggert , bug-gnulib@gnu.org Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" On Friday, May 10, 2019 1:34:55 PM CEST Florian Weimer wrote: > * Kamil Dudka: > >> For example, how do you know that the reports are false positives and not > >> true positives? > > > > I think it was obvious from my previous explanation: > > > > (1) You need to check (by manual review) that the source of data is really > > untrusted. > > > > (2) You need to check (by manual review) that there is no sufficient check > > on the data. > > > > (3) You need to check (by manual review) that the sink function is really > > vulnerable to data from untrusted source. > > > > When doing step (3), I verified that Gnulib's base64_encode() can safely > > process data from untrusted source. Then I wanted to record this > > information into the source code so that other users of Gnulib do not > > need to verify this each time they run Coverity on a project that bundles > > Gnulib's implementation of base64_encode(). > > Does the annotation make the base64 functions trusted in the sense that > they now turn untrusted data into trusted data? That would be > undesirable in my opinion. Nope. The following annotation: /* coverity[-tainted_data_sink: arg-0] */ ... does not affect data sanitization at all, as I understand it. It only tells Coverity that the `in` parameter of base64_encode() is not a taint sink. On the other hand, I do not think that Coverity tracks propagation of tainted data across non-trivial operations on the data (implementation of the base64 algorithm is IMO definitely out of scope). Kamil > Thanks, > Florian