From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.gentoo.org (woodpecker.gentoo.org [140.211.166.183]) by sourceware.org (Postfix) with ESMTP id D666938754A1; Tue, 9 Apr 2024 21:58:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D666938754A1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org D666938754A1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=140.211.166.183 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712699928; cv=none; b=c2/ag0YzJuFY/WmXk2c0gjXM5P3G2iech89dJNzvA0/VffBBGYNCWPNnZJ1AN+q0ya3arau2zLZTz8kkokc80XYZ9GUp/tE5D3S9cBau4ZRr47xqwa7D91r/jfsX7F4Uc0ea3psEFCJrFmAzxQU7PtYE1gQ0AeZVYPkvRCLxTE0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712699928; c=relaxed/simple; bh=onrOtXDSPjrlxE+8PI4RHztIo5hp2cp002eeqDNi6rs=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=X2J3JKoTEn/C0c4D9pmKy1x4hFViLqsV1CU9q5tz2BV1jhAcREEZkYc8gxezE5ZxlPoEE2CUZRyp7sXwRJfUjjjHXKQVrywHtfhDBR/Y1x3K13IRZDxiSb4uLI/bvsC0hbbJRRJ8Wan/Gtm7oxp7mBriAcm9tSqjY3+xTb1Y9K0= ARC-Authentication-Results: i=1; server2.sourceware.org From: Sam James To: Paul Eggert Cc: noloader@gmail.com, Paul Koning , Jonathon Anderson , Andreas Schwab , Michael Matz , Martin Uecker , Ian Lance Taylor , Sandra Loosemore , Mark Wielaard , overseers@sourceware.org, gcc@gcc.gnu.org, binutils@sourceware.org, gdb@sourceware.org, libc-alpha@sourceware.org Subject: Re: Sourceware mitigating and preventing the next xz-backdoor In-Reply-To: <7515b86c-f5d1-49fc-a462-8f9005bc462f@cs.ucla.edu> (Paul Eggert's message of "Tue, 9 Apr 2024 14:50:52 -0700") Organization: Gentoo References: <20240329203909.GS9427@gnu.wildebeest.org> <20240401150617.GF19478@gnu.wildebeest.org> <12215cd2-16db-4ee4-bd98-6a4bcf318592@cs.ucla.edu> <6239192ba9ff8aad0752309a54b633dc75a57c77.camel@tugraz.at> <8e877d2f-01e0-c786-dea5-265edbdc0c07@suse.de> <41394737-6f2d-86e7-5742-e0a794f9f63c@suse.de> <4dd125546c920da4cc744a93f230917a7311c7fb.camel@gmail.com> <87h6gazafa.fsf@igel.home> <62A5C6AE-FE86-48EA-8E0D-E1B17959C8EA@comcast.net> <7515b86c-f5d1-49fc-a462-8f9005bc462f@cs.ucla.edu> User-Agent: mu4e 1.12.2; emacs 30.0.50 Date: Tue, 09 Apr 2024 22:58:39 +0100 Message-ID: <87y19mxkog.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-4.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,URIBL_SBL_A autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Paul Eggert writes: > On 4/9/24 14:40, Jeffrey Walton wrote: >> Code provenance and code integrity was not enforced. Part of the >> problem is the Autotools design. It is from a bygone era. > > No, Andreas is right. This isn't an Autotools-vs-Meson thing. > > Most of the Autotools-based projects I help maintain would have been > immune to this particular exploit, partly because they don't maintain > their own of Gnulib .m4 files. Conversely, any Meson-based project > that had the same sort of out-of-repository sloppiness and lack of > review that xz had, would be vulnerable to similar attacks. > While it could indeed happen via a variety of methods, it's still worth talking about how to reduce places for it to hide in, and make review easier, I think. >> No one should be able to override a named, GNU supplied m4 macro. > > That ship sailed long ago, for Autoconf and for Meson and for every > other widely-available build tool I know of. Everyone can write and > run their own code, whether it comes from GNU or not. That's a feature > that developers want and need. Although this feature can be misused, > it's not a bug per se. Meson doesn't allow user-defined functions and macros to avoid metaprogramming hell: https://mesonbuild.com/FAQ.html#why-doesnt-meson-have-user-defined-functionsmacros.