Am Mittwoch, dem 03.04.2024 um 13:46 -0500 schrieb Jonathon Anderson via Gcc: > Hello all, > > 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 > > > we really still need complex build systems such as autoconf? > > > > (And, FWIW, testing for features isn't "complex". And have you looked at > > other build systems? I have, and none of them are less complex, just > > opaque in different ways from make+autotools). > > Some brief opinions from a humble end-user: > > I think the key difference here is that Autotools allows arbitrarily > generated code to be executed at any time. More modern build systems require > the 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 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 code > 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 > scopes can be audited with more powerful microscopes... and removed if/when > the build system gains first-class support upstream. > > There are other features in the newest build systems listed here (Meson and > Cargo) that make this particular attack vector harder. These build systems > 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 source > 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 > against attacks of this specific design. > > It's also worth noting that Meson and Cargo use non-Turing-complete > declarative DSLs for their build configuration. This implies there is an > upper bound on the [cyclomatic complexity][6]-per-line of the build script > DSL itself. 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. > > Of course, this doesn't make the build system any less complex, but projects > using newer build systems seem easier to secure and audit than those using > overly flexible build systems like Autotools and maybe even CMake. IMHO using > a late-model build system is a relatively low technical hurdle to overcome > for the benefits noted above, switching should be considered and in a > positive light. > > (For context: my team recently switched our main C/C++ project from Autotools > to Meson. The one-time refactor itself was an effort, but after that we got > back up to speed quickly and we haven't looked back. Other projects may have > an easier time using an unofficial port in the [Meson WrapDB][7] as a > starting point.) > > -Jonathon > > [1]: https://mesonbuild.com/External-commands.html > [2]: > https://cmake.org/cmake/help/latest/command/execute_process.html#execute-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
