crates.io still requires a GitHub account. That's a supply chain problem.

What happened

A short post by Matt Taggart (@mttaggart on infosec.exchange) made the Hacker News front page with 163 points and a thesis that fits in a tweet: GitHub should not be a hard dependency for publishing on crates.io. Today, the Rust package registry offers exactly one way to authenticate as a publisher — log in with a GitHub account. There is no email signup, no WebAuthn-only path, no federated SSO, no self-hosted identity option. If you cannot log into GitHub, you cannot publish a crate. Full stop.

The HN thread surfaced the usual receipts. In 2019, GitHub abruptly suspended accounts belonging to developers in Iran, Crimea, and Syria to comply with U.S. sanctions, including read access to private repos those developers themselves had created. Accounts have been suspended for username disputes, for automated abuse detection false positives, and for being adjacent to projects GitHub later removed (see: youtube-dl, every time). Each of those suspensions, applied to a Rust crate maintainer today, would also sever their ability to publish security patches to crates.io.

This is not a hypothetical. The Rust Foundation has discussed the coupling internally for years. The crates.io team has acknowledged it. The fix has not shipped.

Why it matters

The interesting question is not whether GitHub is a good identity provider — it is, mostly — but whether *any* single commercial identity provider should be the sole gate to a language's package ecosystem. The answer the rest of the industry settled on, quietly, over the last fifteen years, is no.

Walk the registries:

- npm has its own account system. You can sign up with email, enable 2FA via TOTP or WebAuthn, and never touch GitHub. npm does support GitHub OIDC for trusted publishing from Actions, but that is an option, not a requirement. - PyPI has its own accounts and now strongly encourages trusted publishing via OIDC — from GitHub, GitLab, Google Cloud, ActiveState, or any compliant IdP. The account itself is independent. - RubyGems has its own auth, with 2FA mandatory for popular gems since 2022. - Maven Central runs on Sonatype OSSRH accounts, tied to a verified namespace, fully independent of any code host. - NuGet uses Microsoft accounts but also supports API keys minted by the publisher, decoupled from any specific login provider for CI use. - Packagist (PHP) uses its own accounts with optional GitHub/GitLab/Bitbucket linking.

Crates.io is the only major language registry where the *identity itself* is leased from a third party. The implications cascade. The Rust Foundation does not control the account lifecycle of its publishers. A GitHub TOS violation, a sanctions ruling, a compromised OAuth app, or a quiet policy change at Microsoft becomes a publishing outage at crates.io — and there is no Rust-side appeal because there is no Rust-side account.

The centralization is also more total than it looks. Cargo's default registry is crates.io. Cargo's default git index was *on GitHub* until the sparse-protocol switch in 2023 moved it to crates.io's own CDN. The source for most crates is also on GitHub. A bad day at GitHub historically meant a bad day at every layer of the Rust supply chain simultaneously — index, source, and identity all riding the same SPOF. The sparse index fixed one layer. The identity layer is still uncovered.

The HN comments push back in interesting ways. One camp argues that requiring a real, established GitHub account is itself a Sybil-resistance feature: it makes typosquatting and malicious-package campaigns marginally more expensive than on PyPI or npm, where throwaway accounts are trivial. That is true, but it is also an argument for *requiring proof of some established identity*, not for requiring proof of *one specific commercial identity*. A multi-IdP model with GitHub, GitLab, Codeberg, and email-plus-WebAuthn would preserve most of the friction without the single point of policy failure.

The other pushback is operational: building a real auth system is expensive, and crates.io is a small team. Fair. But this is exactly the kind of infrastructure work the Rust Foundation exists to fund, and the cost of *not* doing it compounds with every new crate published under the current model.

What this means for your stack

If you maintain crates — even one — your publishing pipeline currently has a non-Rust, non-Cargo, non-crates.io single point of failure named Microsoft. Three concrete things to do this week:

First, audit your publish path. Is your `cargo publish` token tied to a personal GitHub account, a shared org account, or a CI-scoped token? Personal accounts inherit personal risk (bans, compromises, the maintainer quitting and revoking access). Move to org-scoped tokens with documented rotation.

Second, mirror your source off GitHub. Codeberg, GitLab, sourcehut, and self-hosted Forgejo all work as the canonical home for a crate's source. The crates.io listing can point at any of them. Most Rust users will never notice. If GitHub goes sideways, your source and issue tracker survive even if your publish path temporarily does not.

Third, if you depend on a crate from a maintainer who could plausibly be sanctioned, suspended, or politically targeted, vendor a known-good version or fork it to a registry you control. Supply-chain resilience is not paranoia when the dependency tree already has one mandatory commercial gatekeeper at the root.

For consumers of crates — which is every Rust developer — the practical exposure is smaller but real. A maintainer locked out of GitHub cannot ship a CVE patch until they regain access or someone forks. Cargo's `[patch]` mechanism handles the short-term workaround. Have you practiced using it under time pressure? If not, now is a cheap time to try.

Looking ahead

The Rust Foundation has the budget and the mandate to decouple crates.io identity from GitHub. The technical work — adding a second IdP, building an email-and-WebAuthn path, migrating existing accounts without breaking the publish keys baked into a thousand CI configs — is unglamorous but tractable. It is roughly a quarter of focused engineering, not a research project. The blocker is prioritization, not feasibility. Watch for two signals: a public RFC on alternative auth in the crates.io repo, and any Foundation budget line item earmarked for registry identity work. Until one of those lands, the next time someone asks why your Rust shop's bus factor is uncomfortably low, the honest answer involves Redmond.