Pre-RFC: procmacros implemented in wasm

[RalfJung]

@H2CO3

Like any code you trust your system with. I never understood this kind of special concern about (proc-)macros: how exactly is it worse to run arbitrary malicious code from a function that is invoked from a proc-macro than a function that is invoked normally? If you run any code on your system, it has the potential of doing (almost) arbitrary damage – and if you don't trust a crate, you shouldn't use it anyway.

Just because we'll never be able to plug all the holes perfectly, that's not a reason to stop trying to plug some of them.

@bjorn3

It is completely sandboxed by default, even with sandboxing disabled, the only non-deterministic part is getting a random value from the OS.

We hope to expand what is possible in non-sandboxed mode though. File system access and starting processes should be possible eventually.

@bjorn3

miri is simply too slow (at least 10x slower than native/wasm due to many checks being performed during execution and no jit) for this purpose.

10x? I wish. It's more around 1000x currently. CTFE probably has less overhead because it does not do all the UB checks. but I still expect it to be more than 100x slower than native code.

@derekdreery

I think the risk of that is pretty much the same as the risk that people upload code to crates.io that contains something malicious,

(Referring to uploading the wrong code.) Strongly disagreed. Code is much easier to verify than binaries, so it makes a huge difference whether the attacker has to upload code or can upload binaries.

I already find the lack of syncing/comparing between GH and crates.io code (for those crates hosted on GH) rather disturbing...