Rust sem crates.io

Artigo original ↗ Discussão no Hacker News ↗

A dependência do Rust do registry centralizado crates.io é questionada como ponto único de falha e elo fraco na cadeia de suprimentos de software, o que leva a comparações com ecossistemas C/C++ que dependem de gerenciadores de pacotes de distribuições Linux como o Debian. Os participantes pesam os trade-offs entre pacotes curados por distros (mais lentos, mais controlados, específicos do SO) e gerenciadores nativos da linguagem como Cargo (rápidos, multiplataforma, com muitas dependências), debatendo segurança, reprodutibilidade e ergonomia para desenvolvedores. Alternativas como mirrors privados, vendoring, ambientes no estilo Nix/Guix e modelos de segurança baseados em capacidades são mencionadas, mas há pouco consenso de que substituir crates.io por empacotamento de distro seja uma melhoria geral.

Resiliência e ponto único de falha

  • Muitos concordam que crates.io é uma dependência central e um SPOF teórico, mas observam mitigações já existentes:
    • cargo vendor para fazer vendoring de todas as deps em um repositório.
    • Proxies/espelhos locais ou on-prem (Artifactory, Nexus, Azure Artifacts, panamax) amplamente usados em empresas.
  • Alguns dizem que espelhar todo o registry (~1 TB) é fácil e torna você independente de crates.io; outros observam que poucos realmente fazem isso.
  • URLs Git, registries alternativos e builds offline são suportados, mas vistos como mais lentos ou mais desajeitados do que o registry principal.
  • O modelo GOPROXY do Go é citado como um bom híbrido: proxies centrais sem uma dependência central rígida.

Lockfiles e comportamento de atualização

  • Lockfiles tornam significativamente mais lento o caminho “nova versão → produção” e já são, na prática, uma etapa de mediação.
  • Esclarecimentos:
    • Para cargo build/run normal em um repositório, Cargo.lock é respeitado.
    • cargo install a partir de crates.io ignora lockfiles a menos que --locked seja usado.
  • Flags como --locked, --frozen e --offline existem para controle mais rígido.
  • Alguns destacam risco residual ao adicionar novas dependências ou executar cargo update sem revisão cuidadosa.

Empacotamento Debian/sistema vs crates.io

  • Proposta: confiar no Debian (e outras distros) para empacotar bibliotecas Rust, tratando-as como libs compartilhadas de C/C++.
  • Defensores: mantenedores de distros e equipes de segurança fornecem revisão extra, atualizações mais lentas funcionam como um buffer de segurança e libs compartilhadas centralizam correções.
  • Críticas:
    • Fragmentação entre dezenas de distros + macOS/Windows torna isso pouco escalável e um fardo para os autores de bibliotecas.
    • Pacotes de distro frequentemente estão desatualizados, faltando ou compilados com opções incompatíveis; isso impulsiona Docker, Nix e vendoring.
    • A revisão do Debian é limitada e não impediu incidentes como o log4j; os benefícios de segurança são vistos como “vibes” em vez de comprovados.

Experiência do desenvolvedor: Rust vs C/C++

  • Muitos descrevem o gerenciamento de dependências em C/C++ e builds entre distros como “pesadelo”; Rust + Cargo “simplesmente funciona” entre sistemas operacionais, muitas vezes anos depois.
  • Outros relatam experiências aceitáveis com distros e libs compartilhadas, especialmente ao mirar uma única plataforma e usar sistemas modernos de build (Meson, pkg-config).
  • Debate entre muitos crates pequenos vs poucas bibliotecas grandes:
    • Pró-pequenos: melhor reuso, composabilidade e ferramentas tornam a profundidade administrável.
    • Pró-grandes: auditoria, governança e gerenciamento de SBOM mais fáceis; menos dispersão de “microdependências”.

Ideias de segurança da cadeia de suprimentos

  • Ferramentas: proxies privados com firewalls de vulnerabilidades, scanners como Packj (análise estática/dinâmica/de metadados) e verificações em CI são frequentemente mencionados, mas reconhecidos apenas como melhor esforço.
  • Limitação fundamental: código sem sandbox e com completude de Turing significa que scanners não conseguem garantir segurança.
  • Forte interesse em modelos baseados em capacidades ou em sandbox (inspirados por WASM/WASI, redução de privilégios no SO), nos quais bibliotecas não podem tocar o sistema de arquivos/rede exceto por capacidades explícitas.
  • Consenso geral de que nem crates.io nem distros sozinhos “resolvem” o risco da cadeia de suprimentos; uma mitigação real exigiria melhores ferramentas, revisões e possivelmente novos modelos de linguagem/runtime.