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.9 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,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 63E481F461 for ; Sun, 1 Sep 2019 22:46:32 +0000 (UTC) Received: from localhost ([::1]:60574 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4YcA-0001a0-Tn for normalperson@yhbt.net; Sun, 01 Sep 2019 18:46:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43888) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1i4Yc6-0001Zi-Cm for bug-gnulib@gnu.org; Sun, 01 Sep 2019 18:46:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1i4Yc4-0004I7-Ul for bug-gnulib@gnu.org; Sun, 01 Sep 2019 18:46:25 -0400 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:47886) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1i4Yc4-0004Fl-MY for bug-gnulib@gnu.org; Sun, 01 Sep 2019 18:46:24 -0400 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 1EC611600AE; Sun, 1 Sep 2019 15:46:19 -0700 (PDT) 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 IqNaPRRgErwv; Sun, 1 Sep 2019 15:46:18 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3FE521600BF; Sun, 1 Sep 2019 15:46:18 -0700 (PDT) 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 rLCqm6Y-dW6a; Sun, 1 Sep 2019 15:46:18 -0700 (PDT) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 164AA1600AE; Sun, 1 Sep 2019 15:46:18 -0700 (PDT) Subject: Re: critique of gnulib To: Jonas 'Sortie' Termansen , Bruno Haible References: <1704385.skmA4EAMxR@omega> <6db86ac1-944f-cc42-cc49-35351f0c9fd8@cs.ucla.edu> <6638d9b2-76f7-f99d-1d65-5e166c9c3791@maxsi.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <20e8b601-7640-4231-8449-3f3cc7f87c45@cs.ucla.edu> Date: Sun, 1 Sep 2019 15:46:16 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: <6638d9b2-76f7-f99d-1d65-5e166c9c3791@maxsi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Gnulib bugs Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Thanks for your thoughtful reply. A few points: Jonas 'Sortie' Termansen wrote: > I object to the notion that truncation is a worse outcome than a buffer > overflow. A buffer overflow is at worst a remote code execution > vulnerability, while a truncation is at worst a program bug (although > that may be exploitable in turn, it is not inherently exploitable). We look at things a different way. Buffer overflows are easily caught by widely-available tools, and if remote code execution is a problem then one ought to be using such tools. In contrast, silent truncation bugs cannot be caught easily and automatically, so these bugs are much harder to find and fix. If one looks at the overall bug burden, silent truncations are probably a worse problem for Gnulib-like code than buffer overflows are. (Integer overflows are probably worse than either.) Of course this is a judgment call and your judgment might differ. Still, there's a lot to say for the GNU tradition of refusing to impose arbitrary limits (as snprintf-using code usually does), and it's reasonable to follow that tradition. > Generally asprintf should be used instead of > sprintf/snprintf because it does the buffer allocation for you and > significantly reduces the risk. asprintf is often a good way to go, and Gnulib uses it. However, like sprintf and snprintf, asprintf mishandles large buffers and so careful code cannot use it to both allocate and format large results - which means that careful code must do the "risky" stuff anyway since asprintf is not up to the task. > To recap, my primary requests are: > > 1) Categorizing gnulib into three parts (replacement functions for when > they don't exist, workarounds for bugs, and utility functions). > > 2) Making it possible to disable the gnulib bug replacements with a > configure command line option. > > 3) Defaulting to assume the best when cross-compiling to unknown systems. (3) shouldn't be that hard to do, though it would be tedious. (2) sounds trickier, since not everybody agrees about what's a "bug" (are we talking about a bug relative to C11? to C99? to POSIX-2017? to current GNU? that sort of thing). I don't see the categories in (1) as being that sharp or useful, but perhaps I'm missing something. To my mind, the most important feature needed is to make it easy to do reliable cross-compiling, by letting the builder supply a method for 'configure' to run a program on the target platform. This would be an Autoconf feature, not a Gnulib feature. It would have addressed many of your problems. It's been on the Autoconf to-do list nearly forever, alas.