Rust without crates.io

Original Article ↗ Hacker News Discussion ↗

Rust’s reliance on the centralized crates.io registry is questioned as a single point of failure and a weak link in the software supply chain, prompting comparisons with C/C++ ecosystems that lean on Linux distribution package managers like Debian. Commenters weigh the trade-offs between distro-curated packages (slower, more controlled, OS-specific) and language-native managers like Cargo (fast, cross-platform, dependency-heavy), arguing over security, reproducibility, and developer ergonomics. Alternatives such as private mirrors, vendoring, Nix/Guix-style environments, and capability-based security models are raised, but there is little consensus that replacing crates.io with distro packaging would be an overall improvement.

Resilience and single point of failure

  • Many agree crates.io is a central dependency and a theoretical SPOF, but note existing mitigations:
    • cargo vendor to vendor all deps in a repo.
    • Local or on-prem proxies/mirrors (Artifactory, Nexus, Azure Artifacts, panamax) widely used in enterprises.
  • Some say mirroring the entire registry (~1 TB) is easy and makes you independent of crates.io; others note few actually do this.
  • Git URLs, alternate registries, and offline builds are supported, but seen as slower or clunkier than the main registry.
  • Go’s GOPROXY model is cited as a nice hybrid: central proxies without a hard central dependency.

Lockfiles and update behavior

  • Lockfiles significantly slow the “new version → production” path and are already a de‑facto mediation step.
  • Clarifications:
    • For normal cargo build/run in a repo, Cargo.lock is respected.
    • cargo install from crates.io ignores lockfiles unless --locked is used.
  • Flags like --locked, --frozen, and --offline exist for tighter control.
  • Some highlight residual risk when adding new dependencies or running cargo update without careful review.

Debian/system packaging vs crates.io

  • Proposal: rely on Debian (and other distros) to package Rust libraries, treating them like C/C++ shared libs.
  • Supporters: distro maintainers and security teams provide extra review, slower updates act as a safety buffer, and shared libs centralize patching.
  • Critics:
    • Fragmentation across dozens of distros + macOS/Windows makes this unscalable and a burden on library authors.
    • Distro packages are often outdated, missing, or built with incompatible options; this drives Docker, Nix, and vendoring.
    • Debian review is limited and didn’t prevent incidents like log4j; security benefits are seen as “vibes” rather than proven.

Developer experience: Rust vs C/C++

  • Many describe C/C++ dependency management and cross-distro builds as “nightmarish”; Rust + Cargo “just works” across OSes, often years later.
  • Others report acceptable experiences with distros and shared libs, especially when targeting a single platform and using modern build systems (Meson, pkg-config).
  • Debate over many small crates vs few large libraries:
    • Pro-small: better reuse, composability, and tooling makes depth manageable.
    • Pro-large: easier auditing, governance, and SBOM management; less “microdependency” sprawl.

Supply-chain security ideas

  • Tools: private proxies with vulnerability firewalls, scanners like Packj (static/dynamic/metadata analysis), and CI checks are commonly mentioned but acknowledged as best-effort only.
  • Fundamental limitation: Turing-complete, unsandboxed code means scanners can’t guarantee safety.
  • Strong interest in capability-based or sandboxed models (inspired by WASM/WASI, OS privilege dropping), where libraries can’t touch filesystem/network except via explicit capabilities.
  • General consensus that neither crates.io nor distros alone “solve” supply-chain risk; real mitigation would require better tooling, reviews, and possibly new language/runtime models.