Hacker News Reader

Comment by cornstalks | Hacker News Reader

How would you do it, then? Sandboxing a project's build.zig via Wasm (and the various dependencies's build.zig files) seems like a great improvement to me and is how I would personally try to sandbox the build process.

View on HN

I don't know what build.zig commonly does, but in Rust build.rs often does things like compiling C/C++ libraries, so you can't sandbox it with WASM (contrary to proc macros, which most of the times can be compiled to WASM and there were/are efforts for that). How does Zig fare with that?

Even if they end up with a "this dependency can execute arbitrary code" it'll be a huge win because that will be an explicit grant to that dependency. You'll be able to know "which of my dependencies execute arbitrary code?" and encourage most of them not to. In rust, you can know this but it's going to be "basically all of my dependencies can do it" because somewhere they'll use a build script/ proc macro.

I don't know Zig's plan, but once you have the ability to broker privileges like this you have the ability to audit the privileges being brokered and things change forever.

I assume the compiler(s) do not run in WASM. Just the build script. The build script just orchestrates the compilers. So you can run any compiler that the build script is given access to, so compiling C/C++ or potentially any other language shouldn’t be an issue.

In theory, you could run the whole compiler (including C) in WASM as well but I don’t think that’s the goal? You kinda need to trust the compiler itself.

If the build script can execute arbitrary processes, the entire security is lost.

Use containerized development systems: bwrap (my favorite), devcontainers.json, isolated server, anything really. You can't protect yourself against malicious vscode extensions with a zig build system sandbox.

Reply on news.ycombinator.com