Los cambios realizados en Github no fueron como esperaban

Hace poco se ha informado que GitHub ha cambiado el método de generar archivos «.tar.gz» y «.tgz» generados automáticamente en las páginas de lanzamiento.

Este cambio provocó cambios en sumas de verificación y fallas masivas en los sistemas de compilación automatizados, que verifican la integridad de los archivos descargados de GitHub contra las sumas de verificación previamente almacenadas, como las que se colocan en los metadatos del paquete o en los scripts de compilación.

A partir de la versión 2.38, de Git, se incluía de forma predeterminada una implementación integrada de gzip, lo que permitía unificar la compatibilidad con 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.

La compresión predeterminada para los archivos de Git ha cambiado recientemente . Como resultado, los archivos descargados de GitHub pueden tener diferentes sumas de verificación aunque el contenido no haya cambiado por completo.<

GitHub no garantiza la estabilidad de las sumas de verificación para archivos generados automáticamente. Estos están marcados con las palabras «Código fuente (zip)» y «Código fuente (tar.gz)» en la pestaña Versiones. Si necesita confiar en una suma de verificación consistente, puede cargar archivos directamente a GitHub Releases.
Estos están garantizados para no cambiar.

El problema era que los archivos comprimidos generados por la implementación gzip incorporada de zlib son binarios diferentes de los archivos generados por la utilidad gzip, lo que da como resultado diferentes sumas de verificación para los archivos creados por diferentes versiones de git cuando se ejecuta el comando «git archive».

En consecuencia, después de actualizar git en GitHub, comenzaron a aparecer archivos ligeramente diferentes en las páginas de lanzamiento que no pasaron la verificación con las sumas de verificación anteriores.

El problema se manifestó en varios sistemas de compilación, sistemas de integración continua y conjuntos de herramientas para compilar paquetes desde el origen. Por ejemplo, se rompieron alrededor de 5800 puertos de FreeBSD, cuyas fuentes se descargaron de GitHub.

En respuesta a las primeras quejas sobre fallas, los representantes de GitHub inicialmente señalaron que nunca se garantizaron sumas de verificación constantes para los archivos.

Después de que se demostró que hacer que los sistemas de compilación se vieran afectados por el cambio requeriría una gran cantidad de trabajo para actualizar los metadatos en los diversos ecosistemas, GitHub cambió de opinión, revirtió el cambio y revirtió el antiguo método de generación de archivos.

Como era de esperar, la gente comenzó a quejarse. La respuesta inicial del empleado de GitHub (y principal colaborador de Git) brian m. carlson fue menos que completamente comprensivo:

Estoy diciendo que la política nunca ha sido correcta y nunca hemos garantizado sumas de verificación estables para los archivos, al igual que Git nunca lo ha garantizado. Pido disculpas por las cosas que no funcionan aquí y que no ha habido una comunicación más clara sobre esto en el pasado, pero nuestra política no ha cambiado en más de 4 años.

Los desarrolladores de Git aún no han tomado una decisión y solo están discutiendo posibles acciones. Las opciones consideradas incluyen recurrir al uso de la utilidad gzip predeterminada; agregando el indicador «–stable» para preservar la compatibilidad con archivos antiguos; vincular la implementación incorporada a un formato de archivo separado; usando la utilidad gzip para confirmaciones antiguas y la implementación integrada para confirmaciones a partir de una fecha determinada; garantizando la estabilidad del formato solo para archivos sin comprimir.

La complejidad de la decisión se explica por el hecho de que la reversión a la llamada de la utilidad externa no resuelve completamente el problema de la invariancia de las sumas de verificación, ya que un cambio en el programa gzip externo también puede provocar un cambio en el archivo.

Actualmente, hay un conjunto de parches para revisión que vuelve al comportamiento predeterminado (invocando una utilidad gzip externa) y usa la implementación integrada cuando la utilidad gzip no está presente en el sistema. Los parches también agregan una nota a la documentación de que no se garantiza que la salida de «git archive» sea estable y que el formato está sujeto a cambios en el futuro.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.