I’m also not entirely clear what’s being proposed here. But opt-in security features sound great. Exposing what crates use those security features is probably a good thing.
It’d be especially cool if, whenever one of your crates got X downloads or Y transitive dependents, crates.io sent you a congratulatory email that also linked to things like “how to set up 2FA” and Rust Bus and whatever else the community feels that “successful” crate authors ought to know about and consider using.
The big risk is in demonizing* crates that don’t use 2FA such that we end up harming the ecosystem instead of making it more secure. For example:
-
Crate
foouses 2FA. Some company decides they only want “secure”/2FA-using dependencies.fooadds a dependency onbarthat does not use 2FA.foogets a complaint because suddenly this is considered a breaking change. -
Crate
abcdecides they only want “secure” dependencies. But they really want to usedef. Soabcdecides to copy paste all ofdef's code into a newabc-defcrate that they can 2FA-publish. Or worse, “vendor”def's code by copy-pasting it directly intoabc. -
crates.io actually does enable this by default. Many crates decide 2FA isn’t worth the hassle, and those crates remain github-only. Then they get a complaint that they aren’t on crates.io, or someone forks/vendors them just to work around that…
Any security proposal that makes these scenarios plausible would be causing more harm than good in my opinion. So until we get to the point where 2FA is as easy for people to deal with as making a Github/crates.io account in the first place, I’d rather not require it.
*I use this particular word because I see significant parallels to this old thread and I happen to agree with nrc’s response to it