Re: Sourceware mitigating and preventing the next xz-backdoor

[Jonathon Anderson <anderson.jonathonm@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3204 bytes --]

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]).\
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