HN Debrief

Why stdx is not on crates.io

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

The post argues that Rust’s real supply-chain problem is not crates.io itself but the sheer number of third-party crates most projects pull in. As a response, the author is building "stdx", a monorepo that bundles dozens of Rust crates and helper libraries outside crates.io, with the idea that teams can trust one curated source instead of hundreds of independent packages. The pitch leans on a broader complaint that Rust’s standard library is too small for everyday backend work, which pushes developers into dependency graphs that feel closer to npm than to Go.

If dependency risk is your concern, put effort into auditing and provenance tools like cargo-vet and into tighter dependency selection, not into replacing a public registry with one person’s Git monorepo. Also treat any security or cryptography library built with heavy AI assistance and vague maintenance guarantees as untrusted until proven otherwise.

Discussion mood

Strongly negative. Most comments saw stdx as a confused answer to a real problem, with criticism focused on centralizing trust in one maintainer, weak provenance, copied code with licensing issues, and especially unsafe claims around AI-assisted cryptography.

Key insights

  1. 01

    Copied crates appear to drop license notices

    The licensing concern is not abstract. One commenter pointed to the stdx copy of itoa and noted that copyright and license text from the original project had been removed. That is a real compliance failure under the MIT license, and it undercuts the project’s claim to be a safer or more trustworthy packaging layer.

    If you evaluate curated dependency bundles, inspect whether upstream license and copyright metadata survive the copy. A project that is sloppy about legal provenance is unlikely to be disciplined about security provenance either.

      Attribution:
    • striking #1
    • greyw #1
  2. 02

    AI-generated crypto was the dealbreaker

    The strongest objection was not just "AI wrote some code." It was that the author described cryptography as manageable through specs and test vectors, which misses the hard part. Conformance tests can show that ciphertexts match expected outputs, but they do not catch constant-time failures, side channels, or bad security judgment. That, combined with earlier writing that experts in the comments mocked as fundamentally unsound, convinced many readers the crypto parts should be treated as unsafe by default.

    Do not adopt a new cryptography library because it passes published test vectors. Require evidence about side-channel resistance, review pedigree, and maintainer judgment before it goes anywhere near production.

      Attribution:
    • tialaramex #1
    • oefrha #1
    • vlovich123 #1
    • FiloSottile #1
    • tptacek #1
  3. 03

    Trust is being centralized, not reduced

    Bundling many crates into one repo sounds simpler, but it changes the trust model in a dangerous way. Instead of evaluating many visible maintainers and releases, you are now betting on one curator, one update process, and one repo history. A commenter also highlighted a GitHub quirk where a dependency pinned by commit hash can still reference an object reachable through a fork, which makes "just use a git rev" less reassuring than it sounds.

    Map the exact trust boundaries in your dependency process. Replacing a registry with Git URLs only helps if you also control provenance, mirrors, review, and allowed commit sources.

      Attribution:
    • tptacek #1
    • worik #1
    • sheept #1
    • testdelacc1 #1
  4. 04

    Rust’s stdlib is small by design

    Several readers pushed back on the idea that Rust simply forgot to ship enough library code. Rust’s standard library is broad at the systems level, but it avoids baking in too many domain-specific abstractions because Rust has to work across embedded, low-level, and performance-sensitive use cases. The cost of a bigger stdlib is not just maintenance. It is locking in mediocre general-purpose choices where specialized data structures or domain libraries often matter.

    When choosing Rust, assume you are buying into a thinner application stack and a richer library ecosystem. If your team wants batteries-included backend defaults, compare that requirement against Go early instead of trying to recreate Go through custom curation.

      Attribution:
    • kibwen #1 #2
    • tialaramex #1
  5. 05

    cargo-vet is closer to the actual fix

    One practical suggestion cut through the packaging debate: use cargo-vet. That framing resonated because it addresses the real operational problem, which is deciding which dependencies and versions your organization trusts, without inventing a parallel distribution channel. The follow-up tied it to an incremental workflow alongside vendoring and trusted revisions rather than a wholesale ecosystem fork.

    If you need a dependency policy now, adopt vetting and vendoring tools that fit existing Cargo workflows. You can get auditability gains without asking your team or the ecosystem to migrate to a bespoke bundle.

      Attribution:
    • insanitybit #1
    • jcgrillo #1
  6. 06

    Package identity on crates.io is still messy

    A separate line of discussion backed the premise that Rust packaging has real rough edges. The example was the crate name solr, which points to an old stub while a different crate, solrstice, appears to be the package people actually use. That fed into a wider argument for namespaces or stronger identity signals, even though commenters also noted namespaces bring hard questions about who gets names and how impersonation is prevented.

    When you depend on Rust packages, do not trust the best-looking crate name alone. Validate active maintenance, download patterns, repository ownership, and whether the package identity model fits your threat assumptions.

      Attribution:
    • NoboruWataya #1
    • andriy_koval #1
    • vlovich123 #1
    • insanitybit #1

Against the grain

  1. 01

    A fatter stdlib still has real value

    Not everyone bought the idea that standard-library breadth is irrelevant. The pro-stdlib case was concrete: for common backend and CLI work, Go lets teams ship useful software with very few external dependencies, which cuts selection overhead and shrinks the surface area that needs review. Another commenter made the same point from Python’s side, saying even imperfect stdlib modules are valuable when you are in constrained environments and cannot pull in better third-party packages.

    If your company mostly builds internal services and tooling, count dependency minimization as a language feature, not just an ecosystem detail. The operational simplicity can outweigh the elegance of a smaller core library.

      Attribution:
    • traceroute66 #1 #2
    • bigstrat2003 #1
  2. 02

    One repo can be easier to audit

    A minority view held that centralization is the point, not a bug. Auditing one curated codebase may be more realistic for a small team than continuously reassessing hundreds of transitive crates and maintainers. That does not make stdx trustworthy today, but it does explain why the idea appeals to security-conscious teams with limited review capacity.

    If you like the single-curator model, apply it internally instead of outsourcing it wholesale. Build a narrow approved-dependencies mirror or monorepo under your own controls rather than trusting a public one by default.

      Attribution:
    • bel8 #1
    • worik #1

In plain english

cargo-vet ↩
A Rust tool for recording and sharing which dependency versions have been audited or approved by an organization.
crate ↩
A Rust package or library that can be published and reused as a dependency.
crates.io ↩
The main public package registry for Rust libraries, similar to npm for JavaScript or PyPI for Python.
crypto ↩
Short for cryptography, the code and algorithms used to secure data through encryption, signatures, and related techniques.
Git rev ↩
A specific Git revision or commit hash used to pin a dependency to an exact repository state.
itoa ↩
A small Rust library for converting integers to strings.
MIT License ↩
A permissive open source software license that allows broad reuse, modification, and commercial use with minimal restrictions.
monorepo ↩
A single source repository that contains many separate packages or components instead of one project per repository.
no_std ↩
A Rust programming mode for environments that cannot use the full standard library, common in embedded or low-level systems.
provenance ↩
The record of where software came from, who published it, and whether that history can be verified.
stdlib ↩
Short for standard library, the core set of libraries shipped with a programming language.
test vectors ↩
Known input and output examples used to check whether an implementation of an algorithm produces the expected results.

Reference links

Project and article references

  • Why stdx is not on crates.io
    The main post explaining why stdx is distributed outside the Rust package registry.
  • stdx project article
    Background article describing stdx itself, including the AI-assisted implementation claims that drew criticism.

Code and packaging examples

  • stdx copy of itoa
    Used as the concrete example where license and copyright notices appeared to be stripped from copied code.
  • solr-rust repository
    Shown as an example of a prominent crate name pointing to an old or low-signal package.
  • solrstice crate
    Mentioned as the package that looks like the actually used Solr client despite not owning the obvious name.
  • stdx placeholder crate on crates.io
    Linked to show that the stdx name on crates.io is already occupied by an older unrelated package.

Registry and ecosystem discussions

  • crates.io issue #326
    Referenced in the side discussion about crates.io account creation and authentication options beyond GitHub.
  • Package management namespaces article
    Shared to support the argument that package registries should support namespaces to improve identity and reduce confusion.

Community reaction