Requiring 2FA to Publish to


Honestly, these conversations are tiresome.

I think rust probably just needs some sort of dedicated infrastructure security team to sort these things out. I am not interested in arguing these things in such a way.

Someone should take ownership of developing a threat model for infrastructure and use that to answer questions like the ones posted in this topic. Bars should be set.

These conversations have reminded me why I much prefer getting paid for my work, at companies with systems in place for this sort of discussion to be had in a semi-sane manner. If a working group for this sort of thing existed, we could answer this by just addressing the existing threat model, discussing implementation, and working to understand the complexity involved. In fact, this would all be driven that way.

So that’s my suggestion. Start there. Pushing for security barriers without that is more painful than I’m willing to tolerate.


I’m pro signing, as well.


I like the idea of a security team! Rust is all about safe code, we should apply that up the chain too, to distribution. I’d be willing to help out in such a team.


Local machine compromise is a hard one to protect against. Here’s another attack:

  • Replace cargo binary with one that uploads tarball with malicious code added.

That binary can still ask for 2FA as usual. It can check all your tokens and ssh keys. Everything is authenticated, just uploads not what you expected.

That’s just a notch more difficult to pull off than stealing of credentials file. 2FA is just a speed bump here.




They are doing the right thing. The lack of proper security is a debt they are now starting to pay, fortunately :slightly_smiling_face:


opt-in is a shame and will have a lot lower impact, but I understand why they chose it - they’re a huge repository with many more packages and maintainers.

No surprise that they went down the 2FA path, it’s pretty obvious.


Whether or not you choose 2FA or something else, as a user I’d be more than happy having an email with a link I had to click on to make the publish happen as long as had a checkbox where I could turn that off should I need to (CI etc.).

Also that gives me the 30 seconds thinking time when I think “oh wait I’ve missed out X” and can then quietly push out another version without anyone else realizing my omission.

I’m not anti-additional security on top of email, but email would be really a low friction start… (and in that email you can encourage crate owners to have additional owners if truck number is too low) (Also +1 to SMS 2FA not being secure)


For what it’s worth the’ve had TOTP-based 2FA since last October. What appears to be new is the package-level flag which requires it for all publishers of that package.


Part of the point here is that without 2FA, there’s no way I can intelligently make that decision. Even if I decide that I trust withoutboats, my decisions about failure aren’t well informed - a bad actor shipping a malware update still looks like a withoutboats update. And cargo update -p failure will cheerfully install that update.


As an option that avoids making any changes to the CLI interface:

Have publish go to a staging area where only the author sees it on, and does a 2FA challenge to release it. This also allows for taking back an accidental publish as a side effect, as the publish isn’t public until you 2FA it.

This sidesteps problems around doing 2FA on the CLI and only requires trusting the browser. The small time disconnect also makes an attack harder as there are two surfaces that would have to both be compromised.

It also works perfectly with automated deployment: it goes to the staging location and you confirm it with “Yes, I expected this publish” and 2FA.

2FA is about mitigating credential theft. If you want ironclad trust you need signing, not 2FA. And any security method is only as secure as the user makes it as any secret can be shared. You can’t just trust the system, you also have to trust the author and their tools.


Sorry, the decision was not to depend on crates which don’t require 2FA to publish. So you wouldn’t depend on failure if I don’t have 2FA enabled.

(I’d also like us to retire the idea that 2FA is a silver bullet - “a bad actor shipping a malware update still looks like a withoutboats update” even if I have 2FA enabled, they just have to be able to generate 2FA codes, just like right now they have to steal my token.)


I’ve got macOS Keychain working in Rust:

If Cargo used the Keychain, it’d make stealing of the login token much more difficult.


Not everyone writes Rust on a Mac, though. That said, a limited set of alternatives might work.


I’ve been working on a multi-provider digital signature library for Rust which (among other things) supports Ed25519 which is used in @withoutboats proposals:

It presently supports YubiHSM2s for Ed25519 hardware key storage.

I’m finishing up adding support for ECDSA with NIST P-256, which would allow usage of things like any PKCS#11 token (e.g. standard Yubikeys or other PIV tokens) or the OS X Keychain/SEP (possibly via security-framework).

All that said, using a memory hard PBKDF to derive a keywrapping key for a digital signature key which is decrypted in host memory and used to compute a signature on a package seems like a reasonable baseline to me which could work everywhere regardless of host OS, and can be implemented in pure Rust: something like argon2rs + miscreant + ed25519-dalek.

If signatures were required on packages, it would accomplish the same goals as what are proposed on this thread (requiring an additional authentication factor to publish packages) while also enabling a mechanism which could eventually be used for end-to-end package integrity.


I tend to agree with this view. It seems like managing the association of public keys to authors would be its own challenge, though, especially if we’re concerned about accepting authentication as a responsibility.


Please don’t make 2FA mandatory. I think that’s not helpful, and harmful.

I begrudgingly enabled 2FA for my GitHub account because the rust-lang org enforces it. I don’t trust the security of my phone very much (too much proprietary stuff, too hard to update), so I don’t usually put anything trustworthy on it, but now my phone is involved in GitHub logins. I can’t see that as an improvement in security, though I have to admit it probably does not decrease security either.

It does, however, pose an additional barrier of entrance. Moreover, the information for how to do 2FA without relying on proprietary software is pretty sparse; GitHub itself only recommends proprietary apps (or, alternatively, wants to know my phone number) – so I can just hope that the open-source app I picked from F-Droid is trustworthy. I consider installing proprietary software as decreasing the security of my device, so that wouldn’t have helped either.

I find it somewhat amusing that I can still log in using a password (a known-to-be-insecure authentication method) but then we paper over that using 2FA. Now that WebAuthn is becoming a thing, let’s please just use key-based logins for everything that matters? I would consider a key-based login to GitHub, with a PW-protected key, to be way more secure than 2FA where one factor is just a password and the other is a phone.

I can’t help but feel that 2FA is hyped as a solution to problems caused by passwords, and frequently touted to be way more effective than it IMHO is.


GitHub supports U2F tokens as well, which are self-contained and provide much stronger authentication (challenge/response with public key cryptography). I’d strongly recommend getting one (or many) of them in general. Newer tokens support WebAuthn, which will be generally usable with Firefox (as opposed to things that depend on Chrome’s weird u2f.js).

For an OSS mobile app for TOTP, check out


I haven’t heard of that before and will check it out, thanks!

EDIT: Oh, these are hardware tokens? Yeah that solves the “I don’t trust my phone”, but also significantly increases the barrier of entrance.

I am now using andOTP, which (on a direct comparison) seemed to have the nicer user experience and (at least in F-Droid) more regular updates.


For some prior art: this blog post by Python dev Donald Stufft seems to have some info on the limits of package signing