I called automation out in my initial post - coming up with a viable workflow is, of course, necessary. I proposed an off-the-cuff solution to this, where you have an ‘opt out’ key that lives on CI.
I don’t think this feature is really worth implementing opt-in. I wouldn’t be against it, but I wouldn’t care or consider it a win.
Opt out would be acceptable, though I’d want something like a ‘reminder’ for the devs to reenable it.
I dislike the idea of relying on crate badges for this (edit: as in, badges are not even a viable option as they expose sensitive account information). It should just be safer.
Which part?
When you call ‘cargo publish’ it requires a second auth.
This directly prevents the issue of stolen tokens. We have seen this issue today with npm.
Opt in would have been mostly useless in this situation (the attack I linked). Enough people would not have done it, and the scope of the attack was large enough (an extremely popular package was compromised), that the attacker likely would have had credentials for a non MFA’d account.
It would be useful to have it for an attacker who only managed to compromise one, or a small number, of tokens. However, I still feel that opt-out is the clear choice.
2FA is an extremely common practice at this point. Anyone pushing code to crates.io is very, very likely to have interacted with it at some point. I do not feel that it adds significant friction to someone adding their first rust crate. I feel that it adds a completely manageable amount of friction to a CI build (having CI secrets is a completely supported, well established concept).
2FA is a lightweight approach, does not require a ton of complexity, has low impact on standard workflows, and could be rolled out incrementally.
So, to address your points individually…
I do not feel that ‘badging’ is the way to go anyways. I feel that opt-out or mandatory is the better approach here. I strongly feel that it should never be public whether someone’s account has 2FA on it - that would be a disaster, as attackers can cut down to exactly who to target. That is simply not viable.
I address this bit above - no tags, no badges. They make us less safe.
This is acceptable. For one thing, I strongly feel that an extreme minority of developers would reject crates.io because it requires 2FA. This is simply not realistic to me - 2FA is extremely common, especially in a developers life. Second, for those who choose not to use 2FA, good. I hope they get forked and the new maintainer uses 2FA. This is standard for other security issues.
The only scenario that is even possible is the third and I really do not feel that you’ve justified the scenario being either likely or a real problem.
