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.
