GitHub ha cambiado el método de generación de los archivos automáticamente generados ‘.tar.gz’ y ‘.tgz’ en las páginas de versiones, lo que ha provocado un cambio en sus sumas de verificación y fallos masivos en los sistemas de construcción automatizados que verifican la integridad comparando los archivos descargados de GitHub con las sumas de verificación guardadas previamente, por ejemplo, almacenadas en los metadatos de los paquetes o en los scripts de construcción.
A partir de la versión 2.38, se incluyó por defecto en las herramientas de Git una implementación integrada de gzip, que permitió unificar el soporte de este método de compresión en diferentes sistemas operativos y mejorar el rendimiento en la creación de archivos. GitHub adoptó el cambio tras actualizar la versión de git en su infraestructura. El problema se originó porque los archivos comprimidos generados por la implementación integrada de gzip basada en zlib son binariamente diferentes de los archivos creados por la herramienta gzip, lo que llevó a diferencias en las sumas de verificación para archivos generados por diferentes versiones de git al ejecutar el comando ‘git archive’.
Por lo tanto, después de la actualización de git en GitHub, se empezaron a entregar archivos un poco diferentes en las páginas de versiones que no pasaban la verificación según las viejas sumas de verificación. El problema se manifestó en varios sistemas de construcción, sistemas de integración continua y herramientas de construcción de paquetes a partir de código fuente. Por ejemplo, se interrumpió la construcción de alrededor de 5800 puertos de FreeBSD, cuyos códigos fuente se descargaban de GitHub.
En respuesta a las primeras quejas sobre los fallos, los representantes de GitHub inicialmente afirmaron que las sumas de verificación para los archivos nunca habían sido garantizadas. Después de que se demostró que para restaurar la operatividad de los sistemas de construcción afectados por el cambio se requeriría un esfuerzo colosal para actualizar los metadatos en varias ecosistemas, los representantes de GitHub cambiaron de opinión, cancelaron el cambio y volvieron al antiguo método de generación de archivos.
Los desarrolladores de Git aún no han llegado a una solución y solo están discutiendo posibles acciones. Se han considerado opciones como revertir al uso de la utilidad gzip por defecto; agregar la bandera "--stable" para mantener la compatibilidad con archivos antiguos; vincular la implementación incorporada a un formato de archivo específico; utilizar la utilidad gzip para commits antiguos y la implementación incorporada para los commits a partir de una fecha específica; garantizar la estabilidad del formato solo para archivos no comprimidos.
La dificultad para tomar una decisión se explica porque revertir a la llamada a una utilidad externa no resuelve completamente el problema de la inmutabilidad de las sumas de verificación, ya que un cambio en el programa externo gzip también podría llevar a un cambio en el formato del archivo. Actualmente, se ha propuesto un conjunto de parches para revisión que devuelve el comportamiento antiguo por defecto (llamada a la utilidad externa gzip) y utiliza la implementación incorporada cuando la utilidad gzip no está presente en el sistema. Los parches también agregan en la documentación una mención de que no se garantiza la estabilidad de la salida de "git archive" y que el formato puede cambiar en el futuro.
Fuente: opennet.ru
