I’ll list various ideas that might reduce the risk with less blow back than crate capabilities. In most cases, these should improve security more by avoiding more likely attack vectors.
Any cross-crate testing infrastructure helps. In particular, trait integration tests would create cross crate testing that increases the chances tests fail when doing strange things. I’d expect other lightweight tools for design by contract and formal verification help too.
There are cargo namespace designs based on maintainer identity that address basically all worries about namespaces, while reducing this risk. Anytime a malicious developer must socially engineers their access to an abandoned but popular crate then the original developer has good odd to make them move the crate to their own namespace, so which dependent crates observe as “more than a version update”.
I also suspect the trend towards micro-crates increases the risk because micro-crates have greater odds for being abandoned. It’s likely “moderate sized collection” crates like itertools that sound less likely to face abandonment. In many cases, collections make no sense, but when they do make sense then they should be pursued within reason.
Instead of crate level capabilities, we need a "capabilities oriented std" that provide a the type system layer for capabilities uses it for a capabilities based IO system. It might work with CloudABI, apparmor, etc., but regardless it pushes Rust developers into building clean capabilities oriented crates, which makes security and auditing easier.
Also, the unsafe blocks in unsafe fn RFC helps against such attacks too.