# Pre-RFC: Sandboxed, deterministic, reproducible, efficient Wasm compilation of proc macros **URL:** \ **Category:** language design\ **Created:** [August 20, 2023, 10:33pm UTC](https://internals.rust-lang.org/t/pre-rfc-sandboxed-deterministic-reproducible-efficient-wasm-compilation-of-proc-macros/19359 "2023-08-20T22:33:46Z")\ **Posts on this page:** 1\ **Showing post:** 5
**Author:** ![kayabaNerve](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/kayabanerve/32/11204_2.png) [@kayabaNerve](https://internals.rust-lang.org/u/kayabaNerve)\ **Post date:** [August 21, 2023, 2:00am UTC](https://internals.rust-lang.org/t/pre-rfc-sandboxed-deterministic-reproducible-efficient-wasm-compilation-of-proc-macros/19359/5 "2023-08-21T02:00:54Z")
> [@dtolnay](#): > > At one point serde\_derive ran an untrusted binary for over 4 weeks across 12 releases before almost anyone became aware. This was plain-as-day code in the crate root; I am confident that professionally obfuscated malicious code would be undetected for years. This is extremely misleading IMO. Multiple issues were opened weeks ago about your usage of binaries. It was solely the community-at-large unaware. If there was a reason to believe the binaries directly malicious, I personally believe the community-at-large would've been made aware with it much sooner. According to pinkforest, you also did trip `cackle`, a tool for automatically checking if crates exceed their claimed scope. * * * If [crates.io](http://crates.io) wants to precompile macros in a reproducible environment, and offer them _as an opt-in feature_, I'd support it despite my complete and continued objections to what happened with serde\_derive on a professional level and the maintainer's actions on a personal level. My sole notable objection to this RFC/pre-RFC has nothing to do with its content, yet rather the process of introducing what's widely considered a security issue into the ecosystem to then further justify changes to the toolchain, holding the security concerns over the ecosystem (RFC commentators, project members, implementers) in the process. It's effectively impossible to fairly review this on its merit now, nor to say it isn't being reviewed on an accelerated time span than it would otherwise have been. For actual RFC feedback, I'd like to object to > [@dtolnay](#): > > If the server-side build does not reproduce a .wasm artifact with the same exact content as the uploaded one, [crates.io](http://crates.io) is notified and the release appears in a permanent yanked-like status. It can be downloaded for forensic analysis using the usual download endpoint, but is impossible to pull into builds, and cannot be unyanked. I believe this should be an error, not a yanked publication. There are several ways non-reproducible builds can be triggered. We shouldn't waste version numbers finding out a reproducible build isn't working when there's no benefit to existing with a yanked status _unless there's some intricacy to the [crates.io](http://crates.io) backend I'm unaware of_. I'll admit inexperience with it. jhpratt seems to have raised the same comment. Then as a question, I'd like to ask how you plan to achieve reproducible wasm builds. From my understanding, depending on the platform built from, different wasm outputs will be created. Is there a proposed mechanism other than always building from x86\_64 (requiring CPU emulation, and not just containerization)? I'd, personally, insist [crates.io](http://crates.io) does verification (not that my personal insistence means anything) in order to ensure publishers don't each setup their own build processes each needing their own replication. I'd also like to note the value in [crates.io](http://crates.io) rebuilding an uploaded artifact (not just performing the build) to ensure reproducible builds are possible (without multiple server-side runs). As for watt, I do not believe it resolved reproducible builds from different host architectures. --- _[View the full topic](https://internals.rust-lang.org/t/pre-rfc-sandboxed-deterministic-reproducible-efficient-wasm-compilation-of-proc-macros/19359)._