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.4 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS, 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.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 1FFD01F910 for ; Tue, 15 Nov 2022 23:09:50 +0000 (UTC) Authentication-Results: dcvr.yhbt.net; dkim=pass (1024-bit key; unprotected) header.d=cs.ucla.edu header.i=@cs.ucla.edu header.b="gsBg+9yp"; dkim-atps=neutral Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ov53a-0006OB-Pa; Tue, 15 Nov 2022 18:09:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ov53X-0006LM-VO; Tue, 15 Nov 2022 18:09:27 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ov53V-0000ou-Sy; Tue, 15 Nov 2022 18:09:27 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id F040116004F; Tue, 15 Nov 2022 15:09:20 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id V2yyU0lyiPV9; Tue, 15 Nov 2022 15:09:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 199F7160091; Tue, 15 Nov 2022 15:09:20 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.9.2 zimbra.cs.ucla.edu 199F7160091 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=78364E5A-2AF3-11ED-87FA-8298ECA2D365; t=1668553760; bh=mGbiPLEgPjyz0kIccMyM8siGwhJhxtEhCc8EZY8vIOI=; h=Message-ID:Date:MIME-Version:Subject:To:From:Content-Type: Content-Transfer-Encoding; b=gsBg+9ypX/Jgl+5y69duMx7edPaaXu9P+N0oOy1rYLD3u9ZtG3e5FrW1TGniC9YtS qJDG5n6NI1/q0coS8xpZNP65vFB5Arkq068EezDYxdyfdMY19lQIH9E4WcmeG7dy1e EWOAwyAfs6EBpzKYFCKne9/DhIXr0fPJ7Eu2SrxU= X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Os0M5ZOtawjh; Tue, 15 Nov 2022 15:09:20 -0800 (PST) Received: from [131.179.64.200] (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id E62E316004F; Tue, 15 Nov 2022 15:09:19 -0800 (PST) Message-ID: <7ee13f9a-f3e9-8b0b-2b02-64527227fcc1@cs.ucla.edu> Date: Tue, 15 Nov 2022 15:09:19 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: How can Autoconf help with the transition to stricter compilation defaults? Content-Language: en-US To: Aaron Ballman Cc: Jonathan Wakely , Zack Weinberg , c-std-porting@lists.linux.dev, autoconf@gnu.org, gcc@gcc.gnu.org, cfe-commits@lists.llvm.org, Gnulib bugs References: <24ed5604-305a-4343-a1b6-a789e4723849@app.fastmail.com> <251923e7-57be-1611-be10-49c3067adf0d@cs.ucla.edu> <7ef0ce03-d908-649a-a6ee-89fea374d2b1@cs.ucla.edu> <9cb106e9-16ff-65ec-6a44-6567c77521dc@cs.ucla.edu> <06a5d2cd-44eb-7404-17f3-ff64dd505427@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=131.179.128.68; envelope-from=eggert@cs.ucla.edu; helo=zimbra.cs.ucla.edu X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org >> Can you cite any examples of a real-world security flaw what would be >> found by Clang erroring out because 'char foo(void);' is the wrong >> prototype? Is it plausible that any such security flaw exists? > CVE-2006-1174 is a possibly reasonable example. CVE-2006-1174 is not an example, because no prototype 'char foo(void);' was involved.[1] Here's a more concrete proposal that should allay any realistic concerns about CVEs. If Clang decides to change its behavior in this area, so that Clang starts to exit with nonzero status if the user declares a function with a prototype incompatible with the C library, it would be a service to real users if Clang merely issues a warning and does *not* error out if the declaration is 'char foo();' (current Autoconf) or 'char foo(void);' (future Autoconf). This may be a hack, but it's a *good* hack. It's likely to fix real-world bugs that would be caused if Clang becomes overly pedantic by default here. And the probability of introducing real-world bugs is essentially zero. > You can run into that same bug > with use of `-Werror` That's OK, as the Autoconf documentation already says "don't do that". And if Clang exits with nonzero status in the above situation when -Werror is specified, that's fine too. [1] CVE-2006-1174 is not even an example of prototype mismatch, as the bad C code did not misdeclare the function in question: it used a POSIX standard include file for the function prototype, which is the standard way to do things.