HN Debrief

GitHub shouldn't be a dependency for publishing Rust on crates.io

  • Open Source
  • Security
  • Programming
  • Developer Tools
  • Infrastructure

The post is about a longstanding design choice in Rust’s package registry, crates.io: you need GitHub as the identity provider to publish crates there. That does not mean crates are hosted on GitHub or that Cargo resolves packages through GitHub the way some ecosystems do. Crates.io distributes source code itself, Cargo can use alternate registries or vendored dependencies, and the GitHub tie is specifically about account identity and publishing rights. That narrower framing changed the tone. The issue is still seen as worth fixing, but not as proof that Rust packaging is fundamentally more GitHub-bound than Go or npm.

If you rely on Rust packaging, treat GitHub login as a known operational and governance risk rather than a surprise, and watch the crates.io auth work now in progress. More broadly, separate "source hosting," "package distribution," and "identity" in your own developer infrastructure so one vendor cannot block the whole workflow.

Discussion mood

Mostly supportive of removing GitHub as the login dependency, with a pragmatic mood rather than outrage. People were frustrated that the issue has existed for years, but the dominant view was that Rust agrees on the problem, already has an RFC and issue trail, and is constrained more by volunteer capacity and risky implementation work than by denial.

Key insights

  1. 01

    There is already an accepted migration path

    Rust has already merged RFC 3963 to let crates.io support additional authentication providers, and implementation work is underway. That turns the story from "nobody is addressing this" into "the project finally has a sanctioned route, but the remaining work is mostly engineering and review on critical infrastructure."

    Track RFC 3963 and the crates.io issue rather than assuming this is stalled in principle. If your team depends on Rust publishing workflows, plan around a transition period instead of waiting for a sudden clean break from GitHub.

      Attribution:
    • epage #1
    • ameliaquining #1
    • vsgherzi #1
  2. 02

    GitHub is only the identity layer

    The dependency is narrower than many package-manager lock-in stories. Crates.io serves source code itself, avoided turning GitHub usernames into package namespaces, and only uses GitHub for login. That leaves far less architectural debt than ecosystems where source hosting, naming, and package retrieval all run through one vendor.

    Model this as an authentication bottleneck, not full platform capture. When comparing ecosystems or designing your own registry, keep identity decoupled from artifact storage and naming from day one.

      Attribution:
    • steveklabnik #1 #2 #3
    • kibwen #1
  3. 03

    Auth fixes do not remove supply-chain risk

    Removing GitHub from publishing would reduce one central point of failure, but it would not change Cargo's core trust model. You still pull third-party code into builds, and projects that care about assurance already lean on vendoring, alternate registries, or private indexes. The deeper risk is executing and shipping code you did not author, not just who handled the login.

    Do not wait for the GitHub decoupling work to solve your package security story. Use vendoring, pinning, private mirrors, and reproducible build practices now if Rust dependencies are part of a sensitive system.

      Attribution:
    • r2vcap #1
    • dboreham #1
    • deathanatos #1
    • hmry #1
  4. 04

    Foundation money is not a magic staffing pool

    The Rust Foundation can fund infrastructure and maintainer time, but it is not set up like a product company with an engineering org that can simply assign a team to backlog items. For work like crates.io auth, the hard part is finding experienced people to implement and review risky changes on critical systems, not just having a legal entity that can receive donations.

    When you depend on open source infrastructure, treat "there is a foundation" as partial support, not guaranteed delivery capacity. Budget for sponsorship or direct engineering help if a missing feature materially affects your business.

      Attribution:
    • NobodyNada #1
    • jojomodding #1
  5. 05

    Crates.io is not mandatory for Rust distribution

    Rust allows private indexes, git dependencies, and path dependencies, and crates.io itself does not host closed-source packages. That means organizations already have escape hatches for proprietary code and for reducing dependence on the public registry, even if the default community workflow runs through crates.io.

    If public-registry policy or availability is a concern, move internal Rust packages to a private index or vendored workflow. You do not need to wait for ecosystem-wide changes to isolate business-critical code.

      Attribution:
    • ecshafer #1
    • hmry #1

Against the grain

  1. 01

    A decade is too long for this excuse

    The blunt critique is that ten years is enough time to remove a login dependency from a package registry, and repeated appeals to complexity or volunteerism start to sound like institutional complacency. That argument cuts through the sympathetic open source framing and asks whether the project has underinvested in an obvious weak point.

    If your company depends on volunteer-run infrastructure, do not confuse community goodwill with guaranteed execution. Build contingency plans around issues that can remain unresolved for years even when everyone agrees they should be fixed.

      Attribution:
    • rho138 #1
    • adamch #1
  2. 02

    Rust is still less GitHub-bound than Go

    The comparison to Go packaging cuts against the original framing. Go makes GitHub usage feel seamless, but in practice that often means even deeper real-world dependence on GitHub-hosted repos. Rust's problem is uglier at login time, yet its package retrieval model is less entangled with GitHub than many assume.

    Be careful using other language ecosystems as the benchmark for registry independence. Convenience can hide stronger vendor dependence than a more visibly centralized auth flow.

      Attribution:
    • lorecore #1
    • fyrn_ #1

In plain english

Cargo ↩
Rust’s standard build tool and package manager, used to fetch dependencies and build projects.
crates.io ↩
The public package registry for the Rust programming language, where developers publish and download reusable libraries called crates.
Go ↩
A programming language developed at Google, also called Golang.
identity provider ↩
A service that handles user login and authentication for another application.
npm ↩
Node Package Manager, the main package ecosystem for JavaScript and Node.js.
PyPI ↩
Python Package Index, the main public repository for Python packages.
RFC ↩
Request for Comments, a formal design proposal process used by many open source projects to discuss and approve major changes.
Rust ↩
A systems programming language focused on performance and memory safety.
vendoring ↩
Copying third-party dependencies into your own repository or controlled storage so builds do not fetch them directly from the public internet.

Reference links

Official Rust proposals and issues

Background explanations and talks

Related concepts and analogies

Examples from other projects

  • janetdocs.org
    Example of another project using GitHub for auth and suffering operational issues because of it.
  • Pangram history example
    Linked in a side discussion about whether a comment looked AI-generated.