On Tue, Apr 9, 2024, 10:57 Andreas Schwab wrote: > On Apr 09 2024, anderson.jonathonm@gmail.com wrote: > > > - This xz backdoor injection unpacked attacker-controlled files and ran > them during `configure`. Newer build systems implement a build abstraction > (aka DSL) that acts similar to a sandbox and enforces rules (e.g. the only > code run during `meson setup` is from `meson.build` files and CMake). > Generally speaking the only way to disobey those rules is via an "escape" > command (e.g. `run_command()`) of which there are few. This reduces the > task of auditing the build scripts for sandbox-breaking malicious intent > significantly, only the "escapes" need investigation and they which > should(tm) be rare for well-behaved projects. > > Just like you can put your backdoor in *.m4 files, you can put them in > *.cmake files. CMake has its own sandbox and rules and escapes (granted, much more of them). But regardless, the injection code would be committed to the repository (point 2) and would not hold up to a source directory mounted read-only (point 3). If your build system is Meson, you can easily consider CMake code to be an escape and give it a little more auditing attention. Or just avoid shipping CMake scripts entirely, they are are rarely necessary. -Jonathon >