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 964133882677; Tue, 9 Apr 2024 22:22:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 964133882677 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 964133882677 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=1712701358; cv=none; b=WlNEBWQHT1ubO/65U9bOlTO6+Xy2aBh66S2t+65tpcLQJDOIBjJmny5ytJ2jxn22GkFdfY7rVpOAmrUpJcZ6rUaZLoP2oPoFFPiB6EgaEW091vs0mkHX/H4ajFBqbYKX1hY9O/KYBoH4gKePNRNImNAhBbwTdmh9rHzYH2whs5g= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712701358; c=relaxed/simple; bh=QA+4xOPQt4T/JILTqXxZJr1Zvc8gj49T4whCHJJsWYs=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=QJzpuoCRuq4zAu9HrpK0TOM83cYTCDwRXqmZE5auJEtV+APFPo9V01jVxLKajMCmkN9RH5NpHjMhLe2yD/Zge7/8jfRn/VMJngIfJH1SMyzKYegDTHDIF/SSGs6ywfr9LF23U06w9Y5ASoYkqrxcE4Yn3fdk8Of0ha6muF3kjjY= 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: <79d33b2f-10fe-43a9-8260-878b78bb5ed6@cs.ucla.edu> (Paul Eggert's message of "Tue, 9 Apr 2024 15:15:21 -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> <87y19mxkog.fsf@gentoo.org> <79d33b2f-10fe-43a9-8260-878b78bb5ed6@cs.ucla.edu> User-Agent: mu4e 1.12.2; emacs 30.0.50 Date: Tue, 09 Apr 2024 23:22:31 +0100 Message-ID: <87zfu2w508.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Spam-Status: No, score=-4.2 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 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: --=-=-= Content-Type: text/plain Paul Eggert writes: > On 4/9/24 14:58, Sam James wrote: >> Meson doesn't allow user-defined functions > > Meson has ways to execute arbitrary user-defined code, so it's not > immune to this sort of exploit. To be clear - not saying it's immune. Just that it scopes the user-defined code part to clearly defined sections. I think it makes sense to optimise for ease of review. > > It's of course better (all other things being equal) to use a build > system with a smaller attack surface. However, any surface of nonzero > size is attackable, so I'm not convinced that Meson is significantly > safer against a determined insider. Although the xz exploit was tricky > and is now famous (hey! the front page of the New York Times!) > fundamentally it was sloppy and amateurish and it succeeded only > because xz's project management was even sloppier. > > Yes, we need to defend against amateurish attacks. But we shouldn't > waste valuable developer time on defenses that won't work against > obvious future attacks and that will likely cost more than they'll > benefit. That's just security theater. Right, I'm not advocating that. It's just easy to go too far the other way too and not change anything because it won't hold up against a state actor. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iOUEARYKAI0WIQQlpruI3Zt2TGtVQcJzhAn1IN+RkAUCZhW/p18UgAAAAAAuAChp c3N1ZXItZnByQG5vdGF0aW9ucy5vcGVucGdwLmZpZnRoaG9yc2VtYW4ubmV0MjVB NkJCODhERDlCNzY0QzZCNTU0MUMyNzM4NDA5RjUyMERGOTE5MA8cc2FtQGdlbnRv by5vcmcACgkQc4QJ9SDfkZBL1QEA3KkK3mvldXq+gQN/M//z9QczqsP8qD3dBNrG tOPVnBABALHvKeeTcMAGs44eOm2OOiS+ugJa07WgF5CYQQFN7CUN =XDNo -----END PGP SIGNATURE----- --=-=-=--