O GitHub alterou o método de geração de arquivos automaticamente gerados "tar.gz" e "tgz" nas páginas de lançamentos, o que levou a mudanças em suas somas de verificação e falhas em massa em sistemas automatizados de construção que, para confirmar a integridade, validam os arquivos baixados do GitHub com somas de verificação previamente salvas, por exemplo, aquelas armazenadas nos metadados dos pacotes ou nos scripts de construção.
A partir da versão 2.38, o Git passou a incluir por padrão uma implementação interna do gzip, o que permitiu padronizar o suporte a esse método de compressão em diferentes sistemas operacionais e melhorar o desempenho na criação de arquivos compactados. O GitHub adotou a mudança após atualizar a versão do git em sua infraestrutura. O problema surgiu porque os arquivos compactados gerados pela implementação interna do gzip baseada em zlib diferem binariamente dos arquivos criados pela ferramenta gzip, o que levou a diferenças nas somas de verificação para arquivos criados por diferentes versões do git ao executar o comando "git archive".
Consequentemente, após a atualização do git no GitHub, arquivos de lançamentos começaram a ser retornados com alguns diferenciais, que não passaram na verificação das antigas somas de verificação. O problema se manifestou em diferentes sistemas de construção, sistemas de integração contínua e em ferramentas de construção de pacotes a partir de textos-fonte. Por exemplo, a construção de cerca de 5800 ports do FreeBSD falhou, cujos textos-fonte foram baixados do GitHub.
Em resposta às primeiras reclamações sobre as falhas surgidas, os representantes do GitHub inicialmente alegaram que as somas de verificação permanentes para os arquivos nunca foram garantidas. Após ser demonstrado que para restaurar a funcionalidade dos sistemas de construção afetados pela mudança seria necessário um trabalho colossal de atualização dos metadados em diferentes ecossistemas, os representantes do GitHub mudaram de opinião, cancelaram a mudança e retornaram ao antigo método de geração de arquivos.
Os desenvolvedores do Git ainda não chegaram a uma solução e apenas discutem as possíveis ações. Foram consideradas opções como reverter para o uso da ferramenta gzip por padrão; adicionar a flag '—stable' para manter a compatibilidade com arquivos antigos; vincular a implementação interna a um formato de arquivo separado; usar a ferramenta gzip para commits antigos e a implementação interna para commits a partir de uma data específica; garantir a estabilidade do formato apenas para arquivos não compactados.
A dificuldade em tomar uma decisão se deve ao fato de que reverter para a chamada da ferramenta externa não resolve completamente o problema da imutabilidade das somas de verificação, pois uma alteração no programa externo gzip também pode levar a uma mudança no formato do arquivo. No momento, um conjunto de patches foi proposto para reverter o comportamento anterior (chamada da ferramenta externa gzip) como padrão e utilizar a implementação interna na ausência da ferramenta gzip no sistema. Os patches também adicionam à documentação a menção de que a estabilidade da saída 'git archive' não é garantida e o formato pode ser alterado no futuro.
Fonte: opennet.ru
