WebAssembly-based sandboxing.

[pfrommerd]

Tools such as nix necessitate the use of linux containerization/MacOS native sandboxing for build isolation and reproducibility.

Unlike nix, brioche is designed more as a build system rather than as a package manager, meaning that build tooling are invoked indirectly via typscript functions. This presents a unique opportunity for brioche of entirely sandboxing the build process by having the host build tools executed in a WebAssembly environment, as opposed to a linux namespace-based container or MacOS sandboxing.

This has the obvious disadvantage of making packaging build tools more difficult (and potentially a small performance penalty?), but it also has many advantages:

1. No cross-compilation. As all build tools are executed in WebAssembly, there is only the target platform of the executable being built. This would allow byte-identical builds for a given target platform on any host platform. This would also enable e.g. builds purely in a browser. This would also allow for hermetic builds on platforms like MacOS and Windows, where sandboxing is not completely hermetic.
2. True determinism. Container-based sandboxes are at best "reproducible" as e.g. multithreaded build tools can introduce nondeterminism in builds. However, single-threaded WASM can be made byte-wise deterministic across platforms. Major WASM engines for rust (e.g. wasmtime or wasmer) already support deterministic execution.
3. Better control over compilation resources. It is difficult to allocate CPUs and memory for build systems with container-based isolation (e.g. https://nix.dev/manual/nix/2.24/advanced-topics/cores-vs-jobs). By contrast, WebAssembly would allow exact control over what is being built where, and would make distributed builds much easier to reason about, as host platforms do not matter, and memory limits can be handled via usespace-managed swap.

The number of packages that brioche has is still small enough to make transitioning to purely WASM-based builds feasible at this stage. I think it is worth considering as a unique and potentially strong selling point for using brioche.

I can try making a proof-of-concept if there is interest in this capability/direction.

[kylewlacy]

Okay, this is definitely something I'm interested in for Brioche! I'd love to eventually support WebAssembly as both a host and a target (and yes, I'd love to see this all work in the browser too!)

The core of Brioche is built around recipes, and the most important is the process recipe. The way I've been thinking about it is that we could support calling a WASI CLI component, which works kinda-sorta like a normal Unix process. At the recipe level, this could even just be exposed as a new platform name (wasm-wasip2, or something).

A few miscellaneous thoughts I have:

• I personally think that Wasm builds should live alongside native builds! I just think that Wasm support isn't widespread enough to offer as the only option today.
• Determinism is a nice goal to have and I'd love to see "fully deterministic" as an opt-in build option, but I don't think it's realistic even as a default. Even for Wasm, I think it'd be better to offer multi-threading for better performance over determinism. Motivating example: LLVM today takes ~2 hours with parallelism on our 16-core x86-64 runner, and ~4 hours on our 8-core aarch64 runner (and it's heavily parallel, so it would easily take more than a day to build without parallelism).

---

I can try making a proof-of-concept if there is interest in this capability/direction.

Yes, I would definitely be interested in that! 🙂 There is a lot of territory to explore around Wasm, so would definitely be interested to see how a proof-of-concept turns out!

The biggest question I have related to Wasm today: what should we do about subprocesses? There's no standard WASI API for spawning subprocesses (yet... see WebAssembly/WASI#414), and I'm not really sure how far things could go without that in Brioche. At minimum, Bash (extremely common in most packages via the std.runBash function) would need subprocesses of course, but it's also very common for compliers to split work into subprocesses: gcc, cargo / rustc, and clang all do this (Cargo issue: rust-lang/cargo#9287; I also know that whitequark had published some Wasm builds of Clang, which would likely be a valuable case study in this space).

A few different directions this question could lead towards:

1. Championing a proposal upstream in WASI to add a proper "spawn process" API. Would take a lot of research/iteration/time before this would unblock us!
2. Come up with our own "spawn process" API and expose it through a Wasm runtime. Then we would patch libc and others to use this API. Probably less time but more maintenance work long-term to keep the patches up-to-date... and may also be useful stepping-stone towards (1)
3. Use WASIX, which already supports process spawning today. This one makes me feel a little uneasy because I haven't seen much adoption of WASIX (I think nearly all the packages that work with WASIX are things that they maintain forks for). They also seem to be glued to WASIp1 rather than moving to WASIp2... which is especially unfortunate because WASIp2 was designed to be easy to bridge to WASIp3 and beyond.
4. Move all "shell glue" to TypeScript (e.g. anywhere we use std.runBash today), and completely avoid spawning processes during builds. There are multiple ways you could slice this, but overall I don't think this would be feasible or realistic in practice...