Sorry I'm just gonna copy some of this directly from tweets about sandboxing that I'd written.

I think it is a mistake to say "cargo build does not need to be sandboxed because cargo test is not". A very tricky part of sandboxing is sandboxing code you don't own. I own what code runs in tests, I do not own what code runs in cargo/ build scripts.

I can take responsibility for isolation in test/ci/prod. Those are tractable problems because I can design my tests/prod code to be friendly to sandboxing. I can not do that with build scripts or proc macros, I can't actually do much at all.

The solution for "sandbox cargo" ends up being "sandbox the entire dev environment", which is a very difficult problem to solve - you lose tons of performance, UX, and the security is lacking due to how much gets placed into the sandbox.

I strongly feel that cargo is in a much better position to help me out here. I can't even know if an update to a crate happened that suddenly added a build script without additional tooling.

As for typosquatting,

> If you think you can remember the URLs for each package you use, you’re probably wrong.

Most people aren't using urls so I don't get this. The issue is typing `cargo add reqwest`. Typosquatting algorithms solve this.

I did some math.

If crates.io had adopted a policy of "no crates within edit distance of one", 15% of crates would have been blocked across all time.

+Exception for same author: 14%

+Exclude <=4: 9%

+Swap from edit distance to actual typo detection algorithm: 5%

5% of crates would have needed a name change across all time. That number will likely decrease drastically as existing names are taken.

Yes, Rust needs radically more funding in these areas. Companies need to step up. Sandboxing, typo squatting, better auditing tools (ie: I need to know when `cargo udpate` adds a dep with a new build script, etc), TUF, etc, all need to be priorities.