[mmastrac]

Yeah, there are already binaries in the crates.io ecosystem, and I'm certain that almost none of these people have audited a `build.rs` file or a proc macro implementation which effectively runs as you, completely unsandboxed.

EDIT: I was wrong, this is not actually `watt` -- it may have been re-using code from the project.

This one of those pile-ons where everyone gets excited about having a cause-du-jour to feel passionate about, while simultaneously ignoring issues that are far more pressing.

[Arnavion]

You keep saying this but I suggest you actually look at the code. The precompiled binary is not a sandboxed WASM binary. Despite the name "watt" it has nothing to do with https://github.com/dtolnay/watt . `watt::bytecode` refers to the serialization protocol used by the proc macro shim and the precompiled binary to transfer the token stream over stdio, not anything related to WASM.

Also it's worth noting that even if it was a sandboxed binary ala https://github.com/dtolnay/watt , it's not obvious that distributions or users would be satisfied with that. For example Zig had this discussion with the own WASM blob compiler that they use as part of bootstrapping. https://news.ycombinator.com/item?id=33915321 . As I suggested there, distributions might be okay with building their own golden blobs that they maintain themselves instead of using upstream's, and that could even work in this Rust case for distributions that only care about a single copy of serde for compiling everything. But it's hard for the average user doing `cargo build` for their own projects with cargo registry in `~/.cargo` to do the same replacement.

[amluto]

A really nice (IMO) solution would be to build a wasm blob reproducibly and to ship the blob’s hash, along with a way to download the blob, as part of a release. Then distros could build the blob, confirm that the hash matches, and ship a package that is built from source and nonetheless bit-for-bit identical to the upstream binary.

[mmastrac]

You're right. I misread that code and edited the parent post.

[monocasa]

> almost none of these people have audited a `build.rs` file or a proc macro implementation which effectively runs as you, completely unsandboxed

The biggest orgs tend to run all of their builds sandboxed, including what happens with build.rs. It's part of how they enforce dependency management day to day, but also helps protect against supply chain attacks.

So not everyone does, but enough people do that you can rely on their complaints for the more well trodden parts of the ecosystem.

[mmastrac]

> The biggest orgs tend to run all of their builds sandboxed, including what happens with build.rs. It's part of how they enforce dependency management day to day, but also helps protect against supply chain attacks.

Sandboxing doesn't completely prevent supply-chain attacks. You can avoid getting persistent malware on your CI machines, sure. Exfiltration of tokens and secrets during build? Maybe in a small handful of CI setups where admins have carefully split the source fetch, or limited CI network access to Nexus. Exfiltration of tokens and secrets and/or backdooring after the software has been deployed to production? No, build-time sandboxing doesn't help here at all.

On all developer machines as well? No. Very few big orgs do this and only for mission-critical stuff. Some very important ones have docker-based sandboxed workflows or SSH-to-sandboxed-cluster workflows, or air-gapped laptops but that's very, very rare (I worked in air-gapped environment for a bit and it was a massive pain).

[monocasa]

> Sandboxing doesn't completely prevent supply-chain attacks.

Correct, it's more a defense in depth technique, not a complete defense.

> On all developer machines as well? No. Very few big orgs do this and only for mission-critical stuff.

All builds at Google for instance use the model I laid out including 'developer builds'.

[mmastrac]

Oh wow. I'd be very interested in hearing how they sandbox rust-analyzer. I found a discussion of supporting the analyzer itself by generating config files [1][2], but not how you can sandbox it.

That would be extremely useful as the analyzer is a pretty juicy target and also runs proc-macros/build.rs scripts.

[1] https://github.com/bazelbuild/rules_rust/pull/384

[2] https://bazelbuild.github.io/rules_rust/rust_analyzer.html

[mike-cardwell]

Sandboxing rust-analyzer is fairly easy. Here's how I did it:

https://www.grepular.com/Sandbox_Rust_Development_with_Rust_...

Well, that's a bit out of date now as I use podman, to get around the sudo issues. But that's the basic idea.

[fnordpiglet]

Yeah everywhere I’ve been at back to 1995 does this for high security environments, and if we detected an issue we had security response teams that worked with maintainers and others to remediate.

For lower environments we generally used 3 month or more embargoes on precompiled stuff we couldn’t easily compile ourselves to mitigate some of the supply chain issues if we weren’t directly managing the chain of trust for the binary.