From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx-2023-1.gwdg.de (mx-2023-1.gwdg.de [134.76.10.21]) by sourceware.org (Postfix) with ESMTPS id AE2E43847725; Wed, 3 Apr 2024 19:01:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE2E43847725 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gwdg.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gwdg.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AE2E43847725 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=134.76.10.21 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712170903; cv=none; b=Dy8scjwAGfuB9hvZKr9tELXsndAp+E00aHr3G0mfVnY7RqOjCg4eSOfZ8+IrNC1H1LpLJjXi/hwtHmAcMcrqCvptkz0IFCJ2dVW3zAL7fR57Dn5scxcyXkfVPEFEUViA4ibJfqoz6JZlIQMHfzMeGrAH7QG/noGuAqOEHgiU81U= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1712170903; c=relaxed/simple; bh=rJXQcYtxCalc/wT7XLW3qE2TKOH3oeahT8LNarRoef8=; h=DKIM-Signature:Message-ID:Subject:From:To:Date:MIME-Version; b=x1xcuL7V13L64gPYNh+0CiPa12un956ZBjwNqKIjOYXze+ohh/2JHeNbMzr2bww34YahjLfyYhivb/HX65b0T6OyZLtLjW7I/kITaYQLhTgdi10szJlInMsN77CzeOpRBT+Z3ARcCgWAGkSConbr+bjxeCRk7ceyXnIJGb7adDs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gwdg.de; s=2023-rsa; h=MIME-Version:Content-Transfer-Encoding:Content-Type:References: In-Reply-To:Date:CC:To:From:Subject:Message-ID:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=gvlCnXWLhvKicXZQI1LQIXlwNzOBJek0ILs5ycXvlIo=; b=AajNnYmtb9cwwOlgodViKS8rE9 OeQWnxOCW0QgGjU6XxOeiw7OrDhdxh+GK4jHg9iTzLvFdRqD1E19Byey1xbdegDY4KvNqSlbyXALi WbRHJszIuBdb1hlQsRMkHJYapAcl+ajQK6BQi8dtlh5DFTneBWnWT3RXdtFB0K0PJg490jA/NeruY YN3Q7TaWVqSn6tkwFUea9TTD6BD0bZ6hH8QbWs1DpKCUdKx2mwO0XE1yzC7kbgVzNbPTbHA0JaG4A TAxstGYPuuzVvTAP92KUjvQa0iLfQoDwU83IrrJGdyK6zXr/V7U0e8akR8d9ttfXnXzjjS6I4CpP5 LpVI3TGA==; Received: from xmailer.gwdg.de ([134.76.10.29]:35021) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1rs5rY-005yJO-2y; Wed, 03 Apr 2024 21:01:33 +0200 Received: from excmbx-29.um.gwdg.de ([134.76.9.204] helo=email.gwdg.de) by mailer.gwdg.de with esmtp (GWDG Mailer) (envelope-from ) id 1rs5rY-0000Fw-26; Wed, 03 Apr 2024 21:01:33 +0200 Received: from vra-169-148.tugraz.at (10.250.9.199) by EXCMBX-29.um.gwdg.de (134.76.9.204) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2507.37; Wed, 3 Apr 2024 21:01:26 +0200 Message-ID: <8d84f989031aa34eae919f8ff2d3cb4e60faf6a7.camel@gwdg.de> Subject: Re: Sourceware mitigating and preventing the next xz-backdoor From: Martin Uecker To: Jonathon Anderson , Michael Matz CC: Ian Lance Taylor , Paul Koning , Paul Eggert , "Sandra Loosemore" , Mark Wielaard , , , , , Date: Wed, 3 Apr 2024 21:01:25 +0200 In-Reply-To: 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> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4-2 MIME-Version: 1.0 X-Originating-IP: [10.250.9.199] X-ClientProxiedBy: EXCMBX-05.um.gwdg.de (134.76.9.209) To EXCMBX-29.um.gwdg.de (134.76.9.204) X-Virus-Scanned: (clean) by clamav X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP,URIBL_SBL_A autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Am Mittwoch, dem 03.04.2024 um 13:46 -0500 schrieb Jonathon Anderson via Gc= c: > Hello all, >=20 > On Wed, 2024-04-03 at 16:00 +0200, Michael Matz wrote: > > > My take a way is that software needs to become less complex. Do=C2=A0 > > > we really still need complex build systems such as autoconf? > >=20 > > (And, FWIW, testing for features isn't "complex". And have you looked = at=20 > > other build systems? I have, and none of them are less complex, just= =20 > > opaque in different ways from make+autotools). >=20 > Some brief opinions from a humble end-user: >=20 > I think the key difference here is that Autotools allows arbitrarily gene= rated code to be executed at any time. More modern build systems require th= e use of specific commands/files to run arbitrary code, e.g. CMake (IIRC [`= execute_process()`][2] and [`ExternalProject`][3]), Meson ([`run_command()`= ][1]), Cargo ([`build.rs`][4]).\ To me it seems that Cargo is the absolute worst case with respect to supply chain attacks. It pulls in dependencies recursively from a relatively uncurated list of projects, puts the source of all those dependencies into a=C2=A0 hidden directory in home, and runs Build.rs automatically with user permissions. Martin > IMHO there are similarities here to the memory "safety" of Rust: Rust cod= e can have memory errors, but it can only come from Rust code declared as `= unsafe` (or bugs in the compiler itself). The scope is limited and those sc= opes can be audited with more powerful microscopes... and removed if/when t= he build system gains first-class support upstream. >=20 > There are other features in the newest build systems listed here (Meson a= nd Cargo) that make this particular attack vector harder. These build syste= ms don't have release tarballs with auxiliary files (e.g. [Meson's is very = close to `git archive`][5]), nor do their DSLs allow writing files to the s= ource tree. One could imagine a build/CI worker where the source tree is a = read-only bind-mount of a `git archive` extract, that might help defend aga= inst attacks of this specific design. >=20 > It's also worth noting that Meson and Cargo use non-Turing-complete decla= rative DSLs for their build configuration. This implies there is an upper b= ound on the [cyclomatic complexity][6]-per-line of the build script DSL its= elf. That doesn't mean you can't write complex Meson code (I have), but it = ends up being suspiciously long and thus clear something complex and out of= the ordinary is being done. >=20 > Of course, this doesn't make the build system any less complex, but proje= cts using newer build systems seem easier to secure and audit than those us= ing overly flexible build systems like Autotools and maybe even CMake. IMHO= using a late-model build system is a relatively low technical hurdle to ov= ercome for the benefits noted above, switching should be considered and in = a positive light. >=20 > (For context: my team recently switched our main C/C++ project from Autot= ools to Meson. The one-time refactor itself was an effort, but after that w= e got back up to speed quickly and we haven't looked back. Other projects m= ay have an easier time using an unofficial port in the [Meson WrapDB][7] as= a starting point.) >=20 > -Jonathon >=20 > [1]: https://mesonbuild.com/External-commands.html > [2]: https://cmake.org/cmake/help/latest/command/execute_process.html#exe= cute-process > [3]: https://cmake.org/cmake/help/latest/module/ExternalProject.html > [4]: https://doc.rust-lang.org/cargo/reference/build-scripts.html > [5]: https://mesonbuild.com/Creating-releases.html > [6]: https://en.wikipedia.org/wiki/Cyclomatic_complexity > [7]: https://mesonbuild.com/Wrapdb-projects.html