Git 3.0 e SHA-256: por que tornar o novo hash padrão pode ser um erro

O que é o SHA-256 no contexto do Git

O Git usa um algoritmo de hash para identificar cada objeto no repositório: commits, trees, blobs e tags. Cada vez que você faz um commit, o Git calcula um hash criptográfico do conteúdo e usa esse hash como identificador único. Você provavelmente conhece esses hashes: são os 40 caracteres hexadecimais que aparecem em git log.

Desde o inicio, o Git usou SHA-1 como algoritmo de hash. Um hash SHA-1 tem 160 bits e gera aqueles identificadores de 40 caracteres. O SHA-256, como o nome sugere, gera hashes de 256 bits, resultando em identificadores de 64 caracteres.

O suporte experimental ao SHA-256 existe no Git desde a versão 2.29, lançada em 2020. A discussão sobre tornar SHA-256 o padrão no Git 3.0 e o que o artigo do GitButler crítica como uma decisão potencialmente cara e desnecessária para a maioria dos projetos.

Por que o SHA-1 virou um problema (e por que pode não ser tao grave)

Em 2017, pesquisadores do Google demonstraram o SHAttered attack: a primeira colisão SHA-1 prática, onde dois arquivos PDF diferentes geravam o mesmo hash SHA-1. Isso foi alarmante porque, em teoria, um atacante poderia criar um commit malicioso com o mesmo hash de um commit legítimo.

A resposta do Git foi rápida. Desde o Git 2.13 (2017), o Git detecta automaticamente colisões SHA-1 usando a técnica de hardened SHA-1. Na prática, o Git atual já e imune ao SHAttered e a ataques de colisão conhecidos do SHA-1. A vulnerabilidade teórica existe, mas o Git já a mitiga.

O argumento central do GitButler e este: o Git já resolveu o problema prático de segurança do SHA-1. Migrar para SHA-256 como padrão seria um esforço enorme para resolver um risco que já foi mitigado.

Como o SHA-256 funciona no Git hoje

Você já pode criar um repositório Git com SHA-256 hoje. E um parâmetro na inicialização:

# Criar repositório com SHA-256
git init --object-format=sha256 meu-projeto

# Verificar o formato do repositório
git rev-parse --show-object-format
# Saída: sha256

Com SHA-256, os hashes dos objetos ficam assim:

# SHA-1 (formato atual padrão)
8f14e45fceea167a5a36dedd4bea2543

# SHA-256 (64 caracteres)
6b86b273ff34fce19d6b804eff5a3f5747ada4eaa22f1d49c01e52ddb7875b4b

O problema e que repositórios SHA-256 e SHA-1 são incompatíveis entre si. Um repositório SHA-256 não pode fazer push para um repositório SHA-1 e vice-versa sem uma camada de tradução. GitHub, GitLab e Bitbucket ainda operam em SHA-1. Nenhum host principal migrou para SHA-256.

Como começar a usar Git com SHA-256 (e por que você provavelmente não deve ainda)

Se você quer experimentar SHA-256, o processo e simples em novos projetos:

# Novo projeto com SHA-256
git init --object-format=sha256 meu-projeto-sha256
cd meu-projeto-sha256
git commit --allow-empty -m "primeiro commit"
git log --oneline
# Mostra hash de 64 chars

Para projetos existentes, a migração e mais complexa. O Git tem suporte experimental a conversão, mas requer que todos os remotes também suportem SHA-256, o que hoje significa que você não pode usar GitHub, GitLab ou Bitbucket normalmente.

O custo real da migração para SHA-256 como padrão

O artigo do GitButler levanta um ponto concreto: tornar SHA-256 o padrão no Git 3.0 não afeta só os novos repositórios. Afeta todo o ecossistema.

Pense no que precisaria ser atualizado: o GitHub teria que migrar centenas de milhões de repositórios ou manter conversão em tempo real. Ferramentas como GitHub Actions, GitLab CI, Jenkins, e qualquer script que processa hashes Git precisaria ser atualizado. Integradores, IDEs, plugins, hooks de pre-commit e sistemas de monitoramento que armazenam SHAs precisariam ser revisados.

O custo não e só técnico. E operacional: treinamento de times, atualização de documentação interna, revisão de processos de auditoria que usam SHAs como identificadores imutáveis de commits aprovados.

Comparação: SHA-1 vs SHA-256 no Git

Para colocar o debate em perspectiva, vale comparar os dois algoritmos no contexto específico do Git:

SHA-1 (padrão atual): 160 bits, 40 caracteres hexadecimais, vulnerabilidade teórica de colisão já mitigada pelo Git desde 2017, compatível com 100% dos hosts e ferramentas, espaço em disco menor para armazenar refs e logs.

SHA-256: 256 bits, 64 caracteres hexadecimais, sem vulnerabilidade conhecida de colisão, incompatível com repositórios SHA-1 sem camada de conversão, sem suporte nos hosts principais, hashes maiores aumentam ligeiramente o tamanho de arquivos de configuração e logs.

A questão do artigo do GitButler não e que SHA-256 seja pior. E que o custo de migração do ecossistema inteiro e desproporcional ao beneficio de segurança, dado que a vulnerabilidade do SHA-1 já foi mitigada na prática.

Pontos positivos e limitações de cada abordagem

Adotar SHA-256 como padrão no Git 3.0 tem argumentos dos dois lados. Do lado favorável: eliminaria a preocupação com colisões SHA-1 para sempre, mesmo contra ataques futuros ainda desconhecidos, e alinharia o Git com práticas criptográficas modernas recomendadas por organismos como o NIST.

Do lado contrario: o ecossistema não esta pronto. Nenhum dos três principais hosts (GitHub, GitLab, Bitbucket) migrou seus repositórios para SHA-256. A incompatibilidade nativa entre os dois formatos criaria um período de transição doloroso. E o beneficio concreto de segurança sobre o SHA-1 com hardened detection e marginal no cenário de ameaças atual.

Casos de uso reais

Dev em empresa com compliance rigoroso (bancos, governo): aqui SHA-256 pode fazer sentido mais cedo. Regulações como FIPS e algumas normas de segurança corporativas já exigem SHA-256 em artefatos auditaveis. Para esses casos, um repositório SHA-256 isolado com espelho pode ser justificável.

Dev em projeto open source no GitHub: nenhum motivo para mudar agora. O GitHub ainda não suporta SHA-256. Ficar em SHA-1 com Git moderno (2.13+) e a escolha prática.

Mantenedor de ferramenta Git (plugin de IDE, CLI, hook): esse grupo deveria estar de olho no cronograma do Git 3.0. Se SHA-256 virar padrão, scripts e ferramentas que assumem hashes de 40 caracteres vao precisar de atualização.

Estudante aprendendo Git: isso não muda nada no aprendizado prático. SHA-1 ou SHA-256, o fluxo de trabalho de commits, branches e merges e idêntico.

Dicas e boas práticas relacionadas ao Git e hashing

Vale a pena se preocupar com isso agora?

Para a maioria dos desenvolvedores: não. O debate sobre SHA-256 como padrão no Git 3.0 e relevante para mantenedores de ferramentas, equipes de segurança e para quem acompanha o desenvolvimento do Git em si. No dia a dia, o Git com SHA-1 e proteção contra colisão e seguro o suficiente.

O que vale monitorar: o cronograma oficial do Git 3.0 e o posicionamento do GitHub e GitLab sobre suporte a SHA-256. Quando os hosts principais anunciarem suporte, esse debate vai ganhar urgência prática. Até la, e uma discussão técnica importante mas sem impacto imediato na maioria dos projetos.

O próximo passo sugerido: leia o artigo original do GitButler (blog.gitbutler.com) e o RFC de SHA-256 no repositório do Git para entender os argumentos técnicos completos dos dois lados.