GitHub cambiou a forma en que xera os arquivos ".tar.gz" e ".tgz" xerados automaticamente nas páxinas de versións, o que provocou cambios nas súas sumas de comprobación e fallos masivos nos sistemas de compilación automatizados que comproban os arquivos descargados de GitHub con outros anteriores para confirmar a integridade. . sumas de verificación almacenadas, por exemplo, colocadas en metadatos de paquetes ou en scripts de compilación.
A partir da versión 2.38, o conxunto de ferramentas Git incluíu unha implementación integrada de gzip por defecto, o que permitiu unificar o soporte para este método de compresión en todos os sistemas operativos e mellorar o rendemento da creación de arquivos. GitHub recolleu o cambio despois de actualizar a versión de git na súa infraestrutura. O problema foi causado polo feito de que os arquivos comprimidos xerados pola implementación integrada de gzip baseada en zlib son binarios diferentes dos arquivos creados pola utilidade gzip, o que deu lugar a diferentes sumas de verificación para os arquivos creados por diferentes versións de git ao executar o comando "git archive".
En consecuencia, despois de actualizar git en GitHub, comezaron a mostrarse arquivos lixeiramente diferentes nas páxinas de lanzamento, que non pasaron a verificación usando as antigas sumas de verificación. O problema manifestouse en varios sistemas de compilación, sistemas de integración continua e ferramentas para construír paquetes a partir do código fonte. Por exemplo, a montaxe de preto de 5800 portos FreeBSD, cuxos códigos fonte foron descargados de GitHub, foi roto.
En resposta ás queixas iniciais sobre os fallos, GitHub citou inicialmente o feito de que nunca se garantiron as sumas de verificación permanentes para os arquivos. Despois de que se demostrou que se necesitaría unha gran cantidade de traballo para actualizar os metadatos en varios ecosistemas para restaurar a funcionalidade dos sistemas de compilación afectados, os representantes de GitHub cambiaron de opinión, reverteron o cambio e devolveron o antigo método de xeración de arquivos.
Os desenvolvedores de Git aínda non tomaron unha decisión e só están a discutir posibles accións. As opcións consideradas incluían volver ao uso da utilidade gzip predeterminada; engadindo a bandeira "--stable" para manter a compatibilidade cos arquivos antigos; vincular a implementación integrada a un formato de arquivo separado; usando a utilidade gzip para commits antigos e a implementación en liña para commits a partir dunha data determinada; garantindo a estabilidade do formato só para arquivos sen comprimir.
A dificultade de tomar unha decisión explícase polo feito de que volver a unha chamada a unha utilidade externa non resolve completamente o problema da inmutabilidade da suma de verificación, xa que un cambio no programa gzip externo tamén pode levar a un cambio no formato do arquivo. Actualmente, propúxose un conxunto de parches para a revisión que devolve o comportamento antigo por defecto (chamando unha utilidade gzip externa) e usa a implementación integrada en ausencia dunha utilidade gzip no sistema. Os parches tamén engaden á documentación unha mención de que a estabilidade da saída do "arquivo git" non está garantida e que o formato pode cambiar no futuro.
Fonte: opennet.ru