Very nice pre-pre-RFC, although I don’t understand why opt-out/allow-by-default/blacklist for many capabilities instead of opt-in/deny-by-default/whitelist? Given that we are explicitly talking about a security/safety/trust problem here, shouldn’t we just be extra vigilant and as strict as possible?
For example, I would very much like "allowed to use
unsafe" to be denied by default. In my experience, many crates that use
unsafe really don’t need the
unsafe. Some programmers use it for “optimization” purposes; others are C programmers trying to avoid learning how to borrowck; and very few are actual, legitimate users who are trying to call into a C library or write a safe primitive to build on.
Related: I am currently working on a project that will explicitly advertise itself as "transitively free of
unsafe". For now, it means that I have gone through every dependency of my project one-by-one, recursively, and verified if/how they use
unsafe in any of the functions/types I am using from them. I’ve also submitted pull requests that remove unnecessary
unsafes from several such depended-upon-by-me crates in the course. In the future, if I update any of these crates, I will need to go through it again.
To mitigate this, I think many of us would appreciate some sort of tooling, e.g.
cargo safe, that would allow one to query and track uses of
unsafe in the transitive dependencies.