In the original context of "if you don't like how crates-io (not) manages abandoned crates, make your own registry" ability to modify crates and their ownership is the whole point.
There's an implicit assumption that user has to trust the registry not to do anything malicious (just like you have to trust cratesio today). I don't see a way around it, because ability to change ownership of crates (and thus ability to modify them) is one of the goals.
Sure, but by default Cargo will only know about crates.io, no? At least, that’s the only sane default beyond “all registries are opt-in”, which is nuts.
I certainly don’t want Cargo hooked up to random registries I don’t trust by default. I implicitly trust (for the purposes of discussion) crates.io, because it’s administered by the same organization that distributes the compiler binaries.
Alternative registries are opt in. Currently it’s a tedious change of config and extra property for every dependency, so there’s no way to use one by accident.
I don’t really understand the problem then (which is on me; I might have skimmed the OP incorrectly). Having Cargo “figure out” which registries to use based off some setting at the top of your buildfile seems like a footgun. If what you want is “I want to use this registry as the default instead of cargo.io”, that is an extremely reasonable knob.
There’s no way to use anything instead of crates-io. You can say “in addition to crates-io, if I specifically say I want a package from another registry that I’m nicknaming “foo”, then check that URL”.