From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id aduwHcmnDWYI0iEAWB0awg (envelope-from ) for ; Wed, 03 Apr 2024 15:02:33 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=iz6hfipd; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 654A11E0C0; Wed, 3 Apr 2024 15:02:33 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5058A1E030 for ; Wed, 3 Apr 2024 15:02:31 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 86A403845147 for ; Wed, 3 Apr 2024 19:02:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 86A403845147 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1712170950; bh=gvlCnXWLhvKicXZQI1LQIXlwNzOBJek0ILs5ycXvlIo=; h=Subject:To:CC:Date:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=iz6hfipdh0UsQgQ0cQtEMoD9TjSGijWqQ+i+B90dMPHjskSPXTYbRisB0pGdagnaU 9e2HrEr4scF1JqqdD+3j61J6H5sdGophlaynHyrQw6s909UBCOcjq3MpXLXSJzeLRC y+mYoILrzDrQv7wQwGoJxCKNN4PuvXc1cZEiOJwM= 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org AE2E43847725 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 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 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 X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Martin Uecker via Gdb Reply-To: Martin Uecker Errors-To: gdb-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb" 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