[pdpi]

Zig build scripts are arbitrary zig programs, so sandboxing those scripts is a Good Thing. Wasm might be overkill, but using something off-the-shelf that's specifically designed for sandboxing untrusted code is definitely the right approach.

[Panzerschrek]

I see no benefits in sandboxing such things as build systems. Sooner or later one eventually needs to execute some external code, like a shell script or cmake. And these external programs can do whatever they want. So, caring about sandboxing within a build system executable is just creating a security theater.

[csande17]

As I understand it, Zig is trying to bring in almost all the stuff that would usually be done by external tools. Zig has its own solution for finding system libraries (instead of pkg-config), it integrates its own C/C++ compiler, and you can do code generation with comptime (or, worst-case, a Zig program that can also be compiled to WebAssembly) instead of an external script. So I think there's a good chance that you'll be able to build most Zig projects entirely inside the sandbox someday.

There's still the obvious problem that if the build system emits malicious code, you'll probably run that code anyway. Personally I think this kind of sandboxing is more useful for enforcing build reproducibility rather than, like, protecting you from viruses in the build.zig file.

[simonask]

I think "build systems" is a too broad category in that argument.

Language-specific build facilities, like Cargo's build.rs and Zig's build scripts, typically have a limited scope - generating a bit of source code, discovering some linker flags, stuff like that. These scripts need to be run by LSP servers when opening the project in an editor to get basic features working, so that's a fairly risky thing.

They are also currently doing things like invoking CMake and other build systems, but you could definitely conceive of a world where that was a separate step in the build process, and that world seems pretty attractive to me.

A common pattern in Rust projects is to have a `*-sys` crate representing the C FFI bindings, and they typically also do something like invoke CMake or similar to actually build the C/C++ library underneath. But if you have a larger project that already integrates multiple build systems, this is really quite inconvenient in most cases.

[Panzerschrek]

Your proposal still contains a security hole, since it still allows executing cmake or something similar. Adding sandboxing in some parts/steps of a build system has no benefits, as soon as the system as whole has loopholes allowing bypassing such sandboxing. It's like adding more locks to the front door, when the backdoor has no locks at all.

[simonask]

Security is not, and in fact can never be, all-or-nothing. An imperfect solution is better than no solution. Developers have the reasonable expectation that opening a project in VS Code does not upload their home directory to a remote server. Performing a full build of a project is a different operation with different associated expectations.