Collider 1.3.0 introduce mejoras de seguridad en la cadena de suministro de software que van más allá de la comprobación de hash de los paquetes. Hasta ahora, la herramienta verificaba que los bytes descargados coincidieran con los registrados en el archivo de bloqueo mediante SHA-256, pero no controlaba de dónde procedían ni cómo se obtenían. La nueva versión corrige dos vías por las que entradas no confiadas podían atravesar esa frontera.
En primer lugar, los índices releases.json de repositorios compatibles con WrapDB utilizan nombres y versiones de paquetes que se convierten en rutas de archivo. Una entrada maliciosa con segmentos como "../../../../etc/cron.d/x" podía escapar del directorio de caché. Collider 1.3.0 centraliza la validación en la función packages_from_releases, que rechaza cualquier nombre o versión que no sea un segmento de ruta seguro (cadenas vacías, ".", "..", separadores o bytes nulos). Las escrituras con nombres no válidos lanzan excepción; las lecturas los descartan y registran en modo debug.
En segundo lugar, las órdenes collider publish y collider unpublish envían un token bearer al endpoint de escritura del repositorio. El abridor urllib de Python reenvía el encabezado Authorization tras redirecciones, lo que podía filtrar el token a otro host o a un intermediario. La función safe_urlopen instala un manejador que descarta la cabecera cuando el origen cambia, conservándola solo en redirecciones al mismo origen. La autenticación en tránsito sigue dependiendo de un proxy inverso con TLS.
Los autores subrayan que el hash demuestra la integridad de los bytes, no la identidad del publicador, y que la firma criptográfica de paquetes es el próximo paso previsto en la hoja de ruta.