Having (optional) not so ideal protection is much better than having none. Also don’t forget about increasing awareness, existence of sandboxing already screams about potentially malicious code.
In some sense sandboxing is similar to borrow checker, we still have soundness and memory-safety issues, but impact is order(s) of magnitude smaller than without it. Yes, it’s discussable whether investment into it is worth the trouble compared to the protection it will provide (reminds C/C++ folk arguments, doesn’t it?), but I strongly disagree with your argument: “sandoxing has limitations, thus we shouldn’t consider it”.
Stuff will happen, there is no ideal defense, does not matter before or after
build.rs, the question is how easy it will be to exploit an opening for an attacker and how much inconvenience will protection create for users?
How the hell is it a dick move??? If I use protection while building something, because in the process it may blow up, and give you the end result for free, why would I be a dick in this situation? As a grown-up you should understand that stuff you got from the stranger can blow up, and it’s up to you if you’ll use protection when using it or will rely on this stranger who in turn relies on dozen of other strangers, with a very fragile chain of trust.
And why do you think that if build process will be sandboxed, the same can’t be done for cargo tools? Protecting developers is more important than protecting users (not saying we shouldn’t care about the latter, it’s about priorities), as otherwise in the worst case scenario we could get an avalanche-like spread of malware across ecosystem. (though reliance on manual
cargo update will reduce spread rate a lot)