O próximo padrão SHA-256 do Git 3.0 será um erro caro

Artigo original ↗ Discussão no Hacker News ↗

A mudança planejada do Git na versão 3.0 de SHA‑1 para SHA‑256 como formato de hash padrão está gerando preocupação de que a alteração fragmente o ecossistema e quebre décadas de ferramentas, referências e fluxos de trabalho que dependem de IDs de commit de 40 caracteres. Críticos argumentam que as fraquezas do SHA‑1 são em grande parte teóricas para o modelo de ameaça real do Git e que hashes mais fortes deveriam ser adicionados como um mecanismo extra de integridade ou assinatura, em vez de substituir o formato central de ID de forma incompatível. Defensores da migração respondem que a segurança de hashes agora é uma exigência regulatória e de cadeia de suprimentos, mas há um temor amplo de que o caminho escolhido se pareça com transições dolorosas passadas, como Python 2→3, especialmente em submódulos, sistemas de CI e repositórios corporativos de longa duração.

Quão grave é a insegurança do SHA‑1?

  • Muitos argumentam que o SHA‑1 já está “quebrado” (colisões de prefixo escolhido, Shambles etc.) e que depender dele para integridade ou assinaturas é inseguro.
  • Outros dizem que ataques práticos em repositórios Git reais continuam extremamente difíceis, especialmente considerando o formato de objetos do Git e a detecção de colisões do sha1dc, e que ataques de cadeia de suprimentos mais prováveis viriam de comprometimento de mantenedores ou da infraestrutura, não de hashes.
  • Há discordância sobre se os hashes do Git são “segurança” ou apenas identificadores de consistência; alguns apontam que assinar commits e fixar por hash implicitamente os torna críticos para a segurança.

Impacto de tornar SHA-256 o padrão

  • Defensores: eventualmente o SHA‑1 precisa ser aposentado; adiar só piora uma futura migração. Os padrões precisam mudar ou ninguém vai se mover.
  • Críticos: mudar o padrão cria dois tipos de repositório incompatíveis, causando confusão, ferramentas quebradas que assumem hashes de 40 caracteres e falhas difíceis de depurar para usuários que não entendem os formatos. Muitos fazem analogia com migrações de IPv6 ou Python 3.

Submódulos, ferramentas e compatibilidade do ecossistema

  • Um grande medo é a quebra de submódulos: pais em SHA‑1 com submódulos SHA‑256 (e vice-versa) costumavam ser descritos como sem suporte.
  • Um comentarista demonstra experimentalmente submódulos SHA‑1 funcionando dentro de um repositório SHA‑256 em versões recentes do Git, mas as garantias de longo prazo e os casos-limite ainda não estão claros.
  • Ecossistemas grandes (Yocto, Nix, CI/CD, gerenciadores de pacotes de linguagens) dependem de hashes de commits; reescritas globais do histórico invalidariam referências em configurações, documentação, rastreadores de issues etc.

Forges e UX (GitHub, GitLab, auto-hospedados)

  • Há preocupação de que as forges exponham aos usuários opções de formato que eles não entendem, ou lidem mal com a autodetecção no primeiro push.
  • Outros contrapõem que os servidores podem inferir o formato a partir do primeiro push e que o plano documentado de transição de hashes do Git inclui mapeamento SHA‑1↔SHA‑256 para interoperabilidade.

Desenhos e propostas alternativas

  • Sugestões populares:
    • Armazenar ambos os hashes por objeto (ou cabeçalhos separados de hash “tree trust”) enquanto mantém IDs SHA‑1 estáveis para endereçamento.
    • Usar digests autoexplicativos no estilo multihash ou permitir múltiplos algoritmos em um único repositório, como o Fossil faz.
    • Manter SHA‑1 como padrão; adicionar SHA‑256 apenas onde segurança ou política exigirem.
  • Oponentes observam que misturar forças de hash pode degradar a segurança geral e complicar a implementação.

Modelos de segurança e questões em aberto

  • Debate sobre caminhos de ataque realistas: contrabando de código baseado em colisão vs. ataques sociais ou de infraestrutura mais simples.
  • Alguns veem a migração como higiene necessária e preparação para o futuro; outros a veem como “teatro de segurança” caro.
  • O que ainda não está claro para muitos: quais garantias exatas o Git 3.0 fornecerá para buscas em SHA‑1, interoperabilidade de submódulos e preservação de referências externas existentes.