crates.io is the official home of Rust's reusable code, and publishing a crate still requires a GitHub account. Two Rust project RFCs are now trying to close a structural gap first flagged a decade ago.
To publish a crate, the standard unit of reusable Rust code, to crates.io, the language's official package registry, a developer still needs a GitHub account. The dependency is not in where the code lives; a crate's source can sit on GitLab, Codeberg, or a developer's laptop. The dependency lives in the doorway. To log in to crates.io, a publisher authenticates through GitHub's OAuth system, and the platform has offered no alternative path for nearly a decade.
The structural gap is not new. The complaint has lived in the rust-lang/crates.io repository since 2015, when issue #326 ("Non-Github account creation") first asked the project to support logins that did not route through Microsoft's developer platform. A decade later, the current tracking issue, #1411 ("Logging in without github") is still open, and the answer to most comments is some version of "we'd love to, but we need a working RFC and engineering time."
That RFC work is now visibly underway. In the rust-lang/rfcs repository, RFC 3946 — proposing a native crates.io username as a vendor-neutral identity, decoupling the registry from any single forge — was merged. A separate proposal, RFC 3944, which would have added Bitbucket Cloud as a non-GitHub OAuth provider, was closed without being merged. Neither is in production today.
What changed in the meantime is that one half of the dependency has already been broken. RFC 3691, "Security Improvements for CI Publishing to crates.io," was accepted and shipped under the banner of "Trusted Publishing." Continuous integration pipelines can now publish releases to crates.io using short-lived OIDC tokens tied to the build environment, not long-lived API keys in a developer's GitHub account. That change removed GitHub from the release publishing step. It did nothing for login.
The distinction matters. A maintainer who today runs cargo publish from a GitHub Actions workflow can do so without ever holding a crates.io API token. The same maintainer still cannot create a crates.io account without clicking "Sign in with GitHub." Trusted Publishing is a CI-level fix; the identity layer above it is what a Mastodon post by infosec.exchange user mttaggart flagged when it re-raised the dependency as a single point of failure. The post, which surfaced on Hacker News as item 48664733, argues that any commercial platform sitting in the publish path of a major language ecosystem is, by definition, a cancellation vector, regardless of intent.
A real disruption does not have to mean a ban. The GitHub account that owns a crate can be suspended, renamed, or transferred. An organization can lose a billing dispute or a security review. Two-factor authentication on the GitHub side can lock a publisher out of their own registry account. None of these require GitHub to act against Rust specifically. They only require the publisher's GitHub identity to be in a bad state at the wrong moment.
The technical surface is smaller than the framing suggests, and larger than Trusted Publishing made it look. crates.io's published Cargo Book reference on publishing describes the workflow in detail and confirms that account-level auth is still GitHub-mediated. The dependency is not a backdoor. It is the only door.
What to watch next is whether crates.io implements the merged RFC 3946 as written, whether RFC 3944 is revived in some form, or whether the decade-old "Non-Github account creation" thread gets a different answer. The native-username proposal is now the more concrete path forward, but the engineering and governance work required to build a second doorway still competes with everything else on the Rust release train.