Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

There's no good reason a proc macro can't run in a no-IO sandbox by default. None. Doesn't require a language change. Doesn't require some microvmcapabilityeffect BS. It requires looking people straight in the eye and saying "no" when they complain about needing to prompt for privileges.


No good reason? Here's a list: https://github.com/dtolnay/watt#remaining-work

(It mostly boils down to "somebody needs to do it". I'd really like proc macros precompiled to wasm by crates.io…)


WASM is totally unnecessary. Vanilla seccomp is sufficient and runs at full performance. What is it with people trying to stick WASM in places it's not needed?

I'd argue that this kind of thing is easier to implement securely and cross-platform with wasm (of course, a performant wasm engine is its own source of complexity).

wasm has the additional benefits of allowing something like pre-compiling binaries once on a central server and thus skipping the CPU cycles for compiling all the macro crate dependencies on every crate compile. So even the people who don't care much about the security benefits have a reason. I'm kind of the "don't care about security" side because (as said elsewhere) it's trivial (https://docs.rs/ctor/latest/ctor/) for any macro to insert code that will run when compiled binaries/tests are run. You need the entire thing in a sandbox anyway, not just the macros, and that's something that can't be provided by cargo by default.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: