O SHA-256 padrão do Git 3.0 é um erro caro, diz Chacon

Scott Chacon diz que o plano do Git de tornar o SHA-256 o hash padrão dos novos repositórios na versão 3.0 será um erro caro. Seu argumento, publicado no blog da GitButler em 30 de setembro de 2026, chega enquanto o próprio projeto Git diz que a troca vai esperar até que o ecossistema esteja pronto. A disputa importa porque toda ferramenta que armazena ou interpreta um identificador de commit do Git é afetada pela resposta.

O Tech AI Wire cobriu o plano do Git 3.0 em setembro. Novos repositórios ganham nomes de objeto SHA-256, o formato reftable e um branch main, e compilar o Git passará a exigir Rust.

O que Chacon argumenta

O Git identifica cada arquivo, pasta e commit por um hash, uma impressão digital de tamanho fixo calculada a partir do conteúdo. O Git usa o algoritmo SHA-1 para isso desde o início. O SHA-1 é conhecido por ser fraco. Com esforço suficiente, pesquisadores conseguem produzir duas entradas diferentes com a mesma impressão digital, o que se chama colisão.

A tese de Chacon é que essa fraqueza é teórica para o Git. Nenhuma colisão foi documentada em bilhões de repositórios Git, escreve ele, apesar das falhas matemáticas conhecidas do SHA-1.

Depois ele lista o custo. Um repositório SHA-256 quebra todos os hashes SHA-1 existentes. URLs, referências a commits em rastreadores de bugs e tudo o mais que cite um identificador de 40 caracteres deixam de bater. A maioria das implementações de bibliotecas Git, diz ele, não tem suporte completo a SHA-256.

A alternativa dele é verificar a integridade sem mudar os nomes dos objetos. Chacon relata que calcular o hash de uma árvore inteira já extraída é rápido. Seus testes levaram cerca de 5 segundos na árvore do Chromium, de 35 GB e 2,1 milhões de arquivos, e 257 milissegundos no kernel Linux, de 1,5 GB. Ele propõe embutir somas de verificação SHA-256 em objetos assinados, ao lado dos nomes SHA-1. Um projeto poderia então verificar com o hash mais forte sem dividir o ecossistema em dois. Ele aponta o git-evtag, uma ferramenta de 2015, como precedente da ideia.

O que o projeto Git diz

O próprio documento de mudanças incompatíveis do Git descreve o plano contra o qual Chacon argumenta. O Git 3.0 muda o hash padrão para SHA-256 apenas em repositórios recém-inicializados. Repositórios SHA-1 existentes continuam funcionando, e o documento diz que não há plano de descontinuar o formato de objetos SHA-1.

O documento também explica por que o projeto quer a mudança. Ele chama o SHA-1 de criptograficamente quebrado e lista as evidências.

Marco	Ano
NIST declara o SHA-1 obsoleto	2011
Ataque SHAppening	2015
Colisão SHAttered	2017
Git escolhe o SHA-256 como sucessor	fim de 2018
Ataque de quase colisão de aniversário	2019
Ataque Shambles	2020

Dois pontos do documento jogam a favor de Chacon. O projeto Git diz que não fará a mudança até que bibliotecas, plataformas de hospedagem e aplicativos de terceiros mostrem que estão prontos para o SHA-256. E não fixa nenhuma data de lançamento para o Git 3.0. Relatos anteriores colocavam o lançamento por volta do fim de 2026; o documento em si não cita data.

Como a transição deve funcionar

O projeto de transição da função hash do Git mostra que o projeto pensou em interoperabilidade. A escolha do SHA-256 remonta ao fim de 2018. O desenho permite que cada repositório migre no seu próprio ritmo. Um repositório SHA-256 mantém uma tabela de tradução nos dois sentidos, de modo que um objeto pode ser referenciado por qualquer um dos hashes durante a transição.

As operações de rede também estão cobertas. O desenho descreve push e fetch entre servidores SHA-256 e SHA-1, convertendo objetos ao empacotá-los. Commits podem carregar duas assinaturas, uma no campo existente gpgsig e outra em um novo campo gpgsig-sha256. O trabalho é dividido em cinco fases e termina com a transição completa quando repositórios suficientes tiverem migrado. Dois limites permanecem: clones rasos e alternates não funcionam entre repositórios SHA-1 e SHA-256.

A diferença visível é o comprimento. Um nome de objeto SHA-1 tem 40 caracteres hexadecimais. Um nome SHA-256 tem 64.

O que isso significa para os desenvolvedores

Nada muda para você hoje. O Git 3.0 não tem data de lançamento, e os repositórios existentes continuam em SHA-1 de qualquer forma. A questão é o que fazer antes que um novo padrão chegue, seja quando for.

Primeiro, teste suas ferramentas agora contra um repositório SHA-256. A afirmação de Chacon de que a maioria das bibliotecas Git não tem suporte completo é verificável. Crie um repositório de teste em modo SHA-256 e rode contra ele seus scripts de integração contínua, hooks de deploy e integrações de revisão de código.

Segundo, audite tudo o que pressupõe um identificador de 40 caracteres. Colunas de banco de dados, expressões regulares e padrões de URL que fixam esse comprimento vão truncar ou rejeitar nomes de 64 caracteres. Nosso artigo de setembro fez o mesmo alerta. O post de Chacon lembra que a quebra se espalha para cada link armazenado.

Terceiro, avalie a alternativa dele pelos próprios méritos. Se a sua preocupação é detectar adulteração, e não a nomenclatura, somas de verificação assinadas sobre a árvore entregam isso hoje sem mudança de formato. Se você precisa de nomes de objeto SHA-256, o desenho da transição já suporta a migração por repositório com interoperabilidade SHA-1. Você não precisa esperar pelo 3.0.

Por fim, observe o teste de prontidão do projeto, e não o número da versão. O documento de mudanças incompatíveis vincula a troca do padrão à prontidão do ecossistema. Isso significa que forges e bibliotecas, e não o calendário de lançamentos do Git, decidem quando isso acontece.