With no_std and an hypothetical no_unsafe and the ability to force these on dependencies in a non-transitive manner, we would be able to build sandbox crates… sort of.
This has a few issues tho:
- no_std is currently transitive
- the requirement of a support crate means the sandbox crate… doesn’t actually sandbox anything, and instead just maintains a global state consisting of a bunch of function pointers (effectively).
Both of these are slightly ugly, so instead I’d like something much more powerful: feature flags on stable and crates.
You see, feature flags don’t modify the code, unlike Cargo features. Instead, they just allow/disallow API usage by downstream crates. This is a much better system for a sandbox crate:
- Rather than doing non-transitive no_std, we can tell the dependency that it’s only allowed to use specific parts of std: atomics, collections, Vec, Box, Arc, Rc, etc.
- We still need a non-transitive no_unsafe.
- We still need a way to disallow dependencies (besides the sandbox crate).
- We can put the sandbox impl in the sandbox crate, behind an feature-flagged API. The dependency wouldn’t be able to access these APIs, but the host crate would. The sandbox crate would be built once, with all its APIs, but only a specific set of APIs would be visible to the dependency.
This would be really nice to have.