Confusión de dependencias: cuando un paquete público eclipsa a uno privado

Qué es

Un instalador convierte un nombre abstracto (spam) en un archivo concreto procedente de algún repositorio. La documentación de pip indica que, cuando se configuran varias ubicaciones de paquetes, no existe prioridad entre ellas: se comprueban todas y se selecciona la mejor coincidencia de versión. El PEP 708 describe la consecuencia: cada repositorio es su propio espacio de nombres, los instaladores los aplanan en uno solo, y cuando el mismo nombre existe en dos repositorios de autores distintos se vuelve posible un ataque de confusión de dependencias. Su ejemplo motivador es torchtriton de PyTorch, pensado para proceder únicamente del índice propio del proyecto, cuyo nombre estaba libre en PyPI y fue publicado allí por un atacante. La documentación de pip advierte de que usar --extra-index-url para paquetes que no están en el repositorio principal es inseguro y nombra el ataque. La misma forma existe en otros ecosistemas siempre que un nombre interno pueda registrarse públicamente.

Por qué importa

El ataque no necesita ningún acceso a los sistemas propios: un agente de compilación, un portátil de desarrollo o un trabajo de integración continua con una configuración de índice permisiva instala el paquete del atacante, cuyos hooks de instalación se ejecutan con las credenciales de la compilación. Los nombres internos se filtran a través de manifiestos, mensajes de error y repositorios públicos, así que la discreción no es una defensa.

Cómo aplicarlo

• Vincular los espacios de nombres a los registros. En npm, asociar un scope a un registro (npm config set @myco:registry=https://...); la documentación indica que un scope apunta exactamente a un registro y que las instalaciones y publicaciones de ese scope van allí. Publicar los paquetes internos solo bajo ese tipo de scope.
• En Python, evitar --extra-index-url para paquetes privados. Usar un único --index-url que apunte a un índice privado que actúe de proxy del público y decida, nombre por nombre, qué origen está permitido, de modo que el instalador vea un solo espacio de nombres.
• Reservar los nombres internos propios en el índice público con paquetes de marcador de posición cuando el ecosistema lo permita.
• Fijar mediante hashes (pip install --require-hashes, archivos de bloqueo con campos de integridad) para que un artefacto sustituido falle la verificación.
• Ejecutar las compilaciones con credenciales mínimas y red saliente restringida, de modo que un hook de instalación malicioso tenga poco que llevarse.
• Auditar la configuración del instalador en las imágenes de integración continua y en los scripts de configuración del desarrollador; la línea peligrosa suele ser una que alguien añadió para conseguir instalar un paquete privado.

Trampas

El PEP 708 proponía metadatos de repositorio («tracks» y «alternate locations») para que los instaladores pudieran detectar automáticamente las mezclas inseguras; fue rechazado tras tres años en aceptación provisional porque las condiciones exigidas nunca se cumplieron, así que quienes usan Python deben configurar la protección por sí mismos. El orden de versiones no es una defensa: el atacante elige la versión superior. Los espejos que fusionan espacios de nombres reintroducen el problema.