GitHub cambió la forma en que genera archivos “.tar.gz” y “.tgz” generados automáticamente en las páginas de lanzamiento, lo que provocó cambios en sus sumas de verificación y fallas masivas en los sistemas de compilación automatizados que comparan los archivos descargados de GitHub con los anteriores para confirmar la integridad. sumas de comprobación almacenadas, por ejemplo, colocadas en metadatos de paquetes o en scripts de compilación.
A partir de la versión 2.38, el kit de herramientas de Git incluyó una implementación integrada de gzip de forma predeterminada, lo que hizo posible unificar el soporte para este método de compresión en todos los sistemas operativos y mejorar el rendimiento de la creación de archivos. GitHub recogió el cambio después de actualizar la versión de git en su infraestructura. El problema fue causado por el hecho de que los archivos comprimidos generados por la implementación gzip integrada basada en zlib son binarios diferentes de los archivos creados por la utilidad gzip, lo que resultó en diferentes sumas de verificación para los archivos creados por diferentes versiones de git al ejecutar el Comando "archivo git".
En consecuencia, después de actualizar git en GitHub, comenzaron a mostrarse archivos ligeramente diferentes en las páginas de lanzamiento, que no pasaron la verificación utilizando las sumas de verificación antiguas. El problema se manifestó en varios sistemas de compilación, sistemas de integración continua y herramientas para crear paquetes a partir del código fuente. Por ejemplo, se rompió el ensamblaje de aproximadamente 5800 ports de FreeBSD, cuyos códigos fuente se descargaron de GitHub.
En respuesta a las quejas iniciales sobre los fallos, GitHub inicialmente citó el hecho de que nunca se garantizaron sumas de verificación permanentes para los archivos. Después de que se demostró que se requeriría una gran cantidad de trabajo para actualizar los metadatos en varios ecosistemas para restaurar la funcionalidad de los sistemas de compilación afectados, los representantes de GitHub cambiaron de opinión, revirtieron el cambio y regresaron al antiguo método de generación de archivos.
Los desarrolladores de Git aún no han tomado una decisión y sólo están discutiendo posibles acciones. Las opciones consideradas incluyeron volver a utilizar la utilidad gzip predeterminada; agregar el indicador “--stable” para mantener la compatibilidad con archivos antiguos; vincular la implementación incorporada a un formato de archivo separado; usar la utilidad gzip para confirmaciones antiguas y la implementación en línea para confirmaciones que comienzan a partir de una fecha determinada; garantizando la estabilidad del formato sólo para archivos sin comprimir.
La dificultad de tomar una decisión se explica por el hecho de que revertir una llamada a una utilidad externa no resuelve por completo el problema de la inmutabilidad de la suma de comprobación, ya que un cambio en el programa gzip externo también puede provocar un cambio en el formato del archivo. Actualmente, se ha propuesto para revisión un conjunto de parches que devuelven el comportamiento anterior de forma predeterminada (llamar a una utilidad gzip externa) y utilizan la implementación incorporada en ausencia de una utilidad gzip en el sistema. Los parches también añaden a la documentación una mención de que la estabilidad de la salida del "archivo git" no está garantizada y que el formato puede cambiar en el futuro.
Fuente: opennet.ru