O GitHub mudou a maneira como gera arquivos “.tar.gz” e “.tgz” gerados automaticamente nas páginas de lançamento, o que levou a alterações em suas somas de verificação e falhas massivas em sistemas de construção automatizados que verificam os arquivos baixados do GitHub em relação aos anteriores para confirmar a integridade. somas de verificação armazenadas, por exemplo, colocadas em metadados de pacotes ou em scripts de construção.
A partir da versão 2.38, o kit de ferramentas Git incluiu uma implementação integrada de gzip por padrão, o que tornou possível unificar o suporte para esse método de compactação em sistemas operacionais e melhorar o desempenho de criação de arquivos. O GitHub percebeu a mudança após atualizar a versão do git em sua infraestrutura. O problema foi causado pelo fato de que os arquivos compactados gerados pela implementação integrada do gzip baseada em zlib são binários diferentes dos arquivos criados pelo utilitário gzip, o que resultou em diferentes somas de verificação para arquivos criados por diferentes versões do git ao executar o Comando "arquivo git".
Assim, após a atualização do git no GitHub, arquivos ligeiramente diferentes começaram a ser exibidos nas páginas de lançamento que não passaram na verificação usando as somas de verificação antigas. O problema se manifestou em vários sistemas de construção, sistemas de integração contínua e ferramentas para construção de pacotes a partir do código-fonte. Por exemplo, a montagem de cerca de 5800 portas do FreeBSD, cujos códigos-fonte foram baixados do GitHub, foi interrompida.
Em resposta às reclamações iniciais sobre as falhas, o GitHub inicialmente citou o fato de que as somas de verificação permanentes dos arquivos nunca eram garantidas. Depois que foi demonstrado que seria necessário muito trabalho para atualizar os metadados em vários ecossistemas para restaurar a funcionalidade dos sistemas de construção afetados, os representantes do GitHub mudaram de ideia, reverteram a mudança e devolveram o antigo método de geração de arquivos.
Os desenvolvedores do Git ainda não tomaram uma decisão e estão apenas discutindo possíveis ações. As opções consideradas incluíam reverter para o uso do utilitário gzip padrão; adicionando o sinalizador “--stable” para manter a compatibilidade com arquivos antigos; vincular a implementação integrada a um formato de arquivo separado; usando o utilitário gzip para commits antigos e a implementação inline para commits a partir de uma determinada data; garantindo estabilidade de formato apenas para arquivos não compactados.
A dificuldade de tomar uma decisão é explicada pelo fato de que reverter para uma chamada para um utilitário externo não resolve completamente o problema da imutabilidade da soma de verificação, uma vez que uma alteração no programa gzip externo também pode levar a uma alteração no formato do arquivo. Atualmente, foi proposto para revisão um conjunto de patches que retorna o comportamento antigo por padrão (chamando um utilitário gzip externo) e usa a implementação integrada na ausência de um utilitário gzip no sistema. Os patches também acrescentam à documentação uma menção de que a estabilidade da saída do "arquivo git" não é garantida e o formato pode mudar no futuro.
Fonte: opennet.ru