Rust sin crates.io

Artículo original ↗ Discusión en Hacker News ↗

La dependencia de Rust del registro centralizado crates.io se cuestiona como punto único de fallo y eslabón débil en la cadena de suministro de software, lo que provoca comparaciones con los ecosistemas C/C++ que se apoyan en gestores de paquetes de distribuciones Linux como Debian. Los comentaristas sopesan las ventajas y desventajas de los paquetes curados por distribuciones (más lentos, más controlados, específicos del SO) frente a gestores nativos del lenguaje como Cargo (rápidos, multiplataforma, con muchas dependencias), debatiendo sobre seguridad, reproducibilidad y ergonomía para el desarrollador. Se plantean alternativas como mirrors privados, vendoring, entornos estilo Nix/Guix y modelos de seguridad basados en capacidades, pero hay poco consenso en que sustituir crates.io por empaquetado de distribuciones suponga una mejora global.

Resiliencia y punto único de fallo

  • Muchos coinciden en que crates.io es una dependencia central y un SPOF teórico, pero señalan mitigaciones existentes:
    • cargo vendor para incluir en el repositorio todas las dependencias.
    • Proxies/mirrors locales o on-prem (Artifactory, Nexus, Azure Artifacts, panamax) ampliamente usados en entornos empresariales.
  • Algunos dicen que replicar todo el registro (~1 TB) es fácil y te hace independiente de crates.io; otros señalan que pocos lo hacen realmente.
  • Se admiten URLs Git, registros alternativos y compilaciones offline, pero se ven como más lentos o torpes que el registro principal.
  • El modelo GOPROXY de Go se cita como un buen híbrido: proxies centrales sin una dependencia central rígida.

Lockfiles y comportamiento de actualización

  • Los lockfiles ralentizan de forma significativa la ruta de “nueva versión → producción” y ya son, de facto, un paso de mediación.
  • Aclaraciones:
    • Para cargo build/run normales en un repositorio, se respeta Cargo.lock.
    • cargo install desde crates.io ignora los lockfiles salvo que se use --locked.
  • Existen flags como --locked, --frozen y --offline para un control más estricto.
  • Algunos destacan el riesgo residual al añadir nuevas dependencias o ejecutar cargo update sin una revisión cuidadosa.

Paquetización Debian/sistema vs crates.io

  • Propuesta: apoyarse en Debian (y otras distribuciones) para empaquetar bibliotecas Rust, tratándolas como bibliotecas compartidas C/C++.
  • Quienes lo apoyan: los mantenedores de distribuciones y los equipos de seguridad aportan revisión adicional, las actualizaciones más lentas actúan como amortiguador de seguridad, y las bibliotecas compartidas centralizan los parches.
  • Críticos:
    • La fragmentación entre decenas de distribuciones + macOS/Windows hace esto poco escalable y supone una carga para los autores de bibliotecas.
    • Los paquetes de distribución suelen estar desactualizados, faltar o compilarse con opciones incompatibles; esto impulsa Docker, Nix y el vendoring.
    • La revisión de Debian es limitada y no evitó incidentes como log4j; los beneficios de seguridad se perciben como “sensaciones” más que como algo demostrado.

Experiencia de desarrollo: Rust vs C/C++

  • Muchos describen la gestión de dependencias en C/C++ y las compilaciones entre distribuciones como “de pesadilla”; Rust + Cargo “simplemente funciona” en distintos SO, a menudo años después.
  • Otros informan experiencias aceptables con distribuciones y bibliotecas compartidas, especialmente al apuntar a una sola plataforma y usar sistemas de compilación modernos (Meson, pkg-config).
  • Debate entre muchas crates pequeñas frente a pocas bibliotecas grandes:
    • A favor de pequeñas: mejor reutilización, composabilidad y la herramienta hace manejable la profundidad.
    • A favor de grandes: auditoría, gobernanza y gestión de SBOM más sencillas; menos dispersión de “microdependencias”.

Ideas de seguridad de la cadena de suministro

  • Herramientas: proxies privados con firewalls de vulnerabilidades, escáneres como Packj (análisis estático/dinámico/metadatos) y comprobaciones en CI se mencionan con frecuencia, aunque se reconoce que solo ofrecen el mejor esfuerzo.
  • Limitación fundamental: el código de Turing, sin sandbox, significa que los escáneres no pueden garantizar la seguridad.
  • Gran interés en modelos basados en capacidades o con sandbox (inspirados en WASM/WASI, la reducción de privilegios del SO), donde las bibliotecas no puedan tocar el sistema de archivos/la red salvo mediante capacidades explícitas.
  • Consenso general en que ni crates.io ni las distribuciones por sí solas “resuelven” el riesgo de la cadena de suministro; una mitigación real requeriría mejores herramientas, revisiones y quizá nuevos modelos de lenguaje/runtime.