Build Security

For the second idea, what about adding a cfg to std that causes its fs implementation to always panic, or something like that? I see this as similar to the wasm32-unknown-unknown target. Then, a macro-may-use-fs list could configure that cfg.

Though, that approach would need to cover other problematic parts of std to be functional: arch, fs of course, net, os, process, ….

And…. I just realized a critical flaw. I know const-eval happens in an interpreter that can catch UB, but what happens if a proc-macro has UB? Malware doesn’t need to be future-proof, and if a proc-macro is compiled to the host’s target (presumably capable of running some form of not-sandboxed assembly), it could conceivably find a way to execute whatever assembly it wants via UB, at least for the current compiler version where the malware author can tweak the code until they see the optimizer doesn’t notice/take advantage of the UB.

Macro sandboxing would need to happen at a lower level than std.