Why stdx skips crates.io, and what it means for Rust packaging

stdx is forcing Rust to confront a question bigger than one repository: what should count as the safe, normal path for packaging? By choosing to live outside crates.io and be consumed directly from source repositories such as GitHub or Codeberg, Sylvain Kerkour’s project turns distribution into a statement about trust, naming, and supply-chain risk, not just convenience.

A deliberate break from Cargo’s default path

Cargo is built around a clear workflow. It downloads dependencies, builds packages, and uploads crates to crates.io, the Rust community’s package registry. Its registry docs describe registries as central locations for uploading, discovering, and searching packages, which is exactly why stdx’s approach stands out so sharply. Instead of joining that central index, stdx is meant to be pulled straight from source.

That choice lines up with the project’s own design goals. The stdx README describes it as Rust’s unofficial extended standard library, says the goal is for stdx to use only code from std and stdx, and says it should avoid third-party packages. It also calls out no_std use cases, which makes the project feel less like a conventional utility crate and more like infrastructure that wants a tightly controlled dependency surface.

The contrast with crates.io is hard to miss. As of June 20, 2026, the crates.io API summary reported about 286,995 crates and more than 340,020,393,018 total downloads. That scale is a strength for discovery and reuse, but it also means the registry sits at the center of Rust’s packaging story. stdx is opting out of that center on purpose.

Why the registry question is really a trust question

Kerkour’s argument is not just about taste. The concern is that a flat registry and a single global namespace create familiar security problems, including typosquatting, dependency confusion, and a larger attack surface whenever developers and CI systems depend on one central index. In other words, the issue is not only where packages live, but what assumptions Cargo and the ecosystem make when they search, resolve, and install them.

Rust’s own security history gives that concern real weight. In 2022, the Rust project documented rustdecimal as an intentional typosquatting attempt against the popular rust_decimal crate. The 2023 crates.io malware postmortem went further, describing typosquatting as a dependency-confusion technique and using proc-macro versus proc-macro2 as the example. In 2025, the Rust blog reported that malicious crates named faster_log and async_println were deleted shortly after detection.

Those incidents matter because they show how small naming differences can become an attack path. If a project is trying to behave like platform infrastructure, or if its users are piping it through automation and CI, the cost of trusting a crowded namespace goes up. stdx’s source-based distribution is therefore not a rejection of Rust packaging so much as an attempt to reduce the number of places an attacker can interfere.

What the debate says about discovery and maintenance

The Hacker News discussion around stdx made one thing clear: this is a controversial position, but not a fringe one. Some commenters pushed back that stdx is not the best example and that Rust already has widely used packages and distribution patterns that do not fit a simple crates.io-centered worldview. That pushback matters, because it shows the ecosystem is already living with multiple assumptions at once.

For maintainers, the difference between crates.io and source-only distribution is practical, not theoretical. A crates.io package gets the benefit of registry discovery, consistent versioning, and an obvious install path. A source-hosted project shifts more responsibility to the maintainer, who has to think harder about naming, repository trust, release flow, and how users will pin and audit updates. That is a different maintenance burden, and one reason the stdx debate resonates beyond the project itself.

It also changes the discovery story for users. On crates.io, the package registry doubles as a search surface. Outside it, the project must be found through code hosting, links, documentation, or direct recommendation. That can be a plus for projects that want tighter control, but it also makes trust and provenance more explicit, which is exactly the tradeoff stdx seems willing to make.

Namespaces are the unresolved part

The wider Rust conversation is already moving in this direction. RFC 3243 proposed optional package namespaces, and the Rust Project Goals for 2026 include work to implement open Rust namespace support. The goals also note that namespace access control on crates.io would require coordination across multiple teams, which tells you this is not a trivial registry tweak.

That context helps explain why stdx landed as more than a branding argument. Rust still does not have a fully settled answer for how namespaced publishing should work, how much authority crates.io should carry, or how to separate ordinary library publishing from infrastructure-style distribution. The Rust Foundation has also been coordinating supply-chain-security work with the Rust Project, including artifact signing and Trusted Publishing on crates.io, and in 2025 it said it received additional funding from Alpha-Omega for that effort. So while stdx is choosing to avoid the registry, the rest of the ecosystem is investing in making the registry safer.

That is the real tension. crates.io is convenient, familiar, and enormous, but infrastructure-sized projects may want something narrower, more explicit, and easier to audit. stdx puts that tradeoff in plain view and makes Rust’s packaging story look less like a settled default and more like a system still deciding what it wants to optimize for.

The bigger lesson for Rust packaging

stdx is not just skipping a registry. It is exposing the fact that Rust still has open questions about what names mean, how packages are discovered, and how much trust a central index should carry. The project’s source-first model makes sense precisely because the ecosystem has already seen typosquatting, dependency confusion, and malicious crates in the wild.

That is why the stdx debate matters even if you never plan to use stdx itself. It is a snapshot of Rust’s next packaging problem: if the language wants an extended standard library, or more projects start shipping from source instead of crates.io, then naming, discovery, and trust will have to evolve with them.