I’m thinking an xz-style attack where a malicious actor submits an “improvement” with an innocuous-looking change to the build script that ends up running arbitrary commands. Running a batch script seems like a reasonable thing for a build script to do (e.g. to run something like i18n or whatever), and a lot of project devs may not know much about how batch scripts work (many devs are more familiar with Linux-compatible shell scripts), so it could slip through. The batch script itself could be innocuous and thus not be caught by a reviewer.
So I don’t think it’s unreasonable to think a developer could sneak in an exploit with “temporary code” to improve some part of the build process on Windows.
I’m thinking an xz-style attack where a malicious actor submits an “improvement” with an innocuous-looking change to the build script that ends up running arbitrary commands. Running a batch script seems like a reasonable thing for a build script to do (e.g. to run something like i18n or whatever), and a lot of project devs may not know much about how batch scripts work (many devs are more familiar with Linux-compatible shell scripts), so it could slip through. The batch script itself could be innocuous and thus not be caught by a reviewer.
But there is no reason to use a script, when you have a build.rs anyways. Since pretty much everything the script can do build.rs can do better.
That’s not going to be particularly feasible when generating bindings and other complex build processes. For example, the Qt bindings run shell commands as part of the build.rs. As does gettext-rs.
So I don’t think it’s unreasonable to think a developer could sneak in an exploit with “temporary code” to improve some part of the build process on Windows.