Olhando com expectativa para o Git 2.56 — e 3.0

Artigo original ↗ Discussão no Hacker News ↗

Os planos para o Git 2.56 e um eventual 3.0 estão provocando debate sobre como migrar de SHA-1 para SHA-256 sem quebrar histórico, ferramentas ou assinaturas, e como verificar a integridade durante essa transição. Os comentaristas também avaliam os benefícios e as desvantagens de introduzir Rust para internos mais seguros, adotar novos mecanismos de armazenamento como reftable e backends pluggáveis em vez de refs baseadas no sistema de arquivos, e melhorar problemas antigos de usabilidade, como estilos de conflito, padrões e suporte a change IDs. Questões mais amplas de segurança também surgem, incluindo como escolhas de *hash* interagem com ameaças quânticas e se mudanças incrementais realmente melhoram a segurança em uma grande base de código em C.

Migração para SHA-256 e reescrita do histórico

  • Vários comentários debatem se a mudança de SHA-1 para SHA-256 exige force-pushes e reescritas do histórico.
  • Preocupações: risco de adulteração do histórico durante force-pushes; invalidação de referências baseadas em SHA em issues, comentários e código; quebra de shallow clones; invalidação de assinaturas de commits existentes.
  • Alguns observam que os blobs de conteúdo não mudam, então é possível recalcular hashes e comparar históricos SHA-1 e SHA-256, mas isso não impede corrupção do histórico.
  • Outros destacam que o Git não misturará livremente repositórios SHA-1 e SHA-256 (por exemplo, submodules), o que implica configurações de dois repositórios de longa duração e tabelas de mapeamento.
  • A documentação sugere que a mudança é mais parecida com um repack com camadas de compatibilidade e tabelas de busca, e não apenas uma troca brusca.

Adoção de Rust no Git

  • Um lado argumenta que Rust está sendo “imposto” desnecessariamente e que uma pequena parte em Rust não melhora significativamente a segurança.
  • Outros respondem que:
    • Melhorias incrementais importam, especialmente para novo código e parsers, onde C tem um longo histórico de CVEs de segurança de memória.
    • Usar linguagens mais seguras para novos componentes é racional, mesmo que o C legado permaneça.
  • Há discussão sobre abordagens alternativas de “C seguro” (por exemplo, Fil-C), observando trade-offs de desempenho e memória.

Backends de armazenamento, refs e reftable

  • Alguns querem que o Git “abandone arquivos lentos” por um “banco de dados de verdade”.
  • Contraponto: o sistema de arquivos já é um banco de dados não relacional; os problemas de desempenho vêm de casos de uso mais recentes (muitas refs, fluxos de trabalho no estilo hub).
  • Há trabalho em andamento em backends pluggáveis (reftable para refs; armazenamentos alternativos de objetos como SQLite, S3 etc.).
  • O reftable é elogiado por resolver problemas de nomes de refs/caminhos e de sensibilidade a maiúsculas/minúsculas, mas a compatibilidade com ferramentas (por exemplo, libgit2, integrações de shell) é uma preocupação.

Padrões, UX e recursos de fluxo de trabalho

  • Pedidos para que o Git 3.0 corrija “padrões ruins”, incluindo:
    • Padrões de push mais seguros (--force-with-lease, configuração automática de remoto).
    • Melhor estilo de conflitos (zdiff3), diffs de submodules e recursão aprimorados, e rerere ativado.
  • Alguns defendem “change IDs” padronizados para commits (como usados por Gerrit, jj, GitButler) para dar suporte a revisão por commit, mudanças empilhadas e IDs estáveis através de rebases; comandos atuais do Git frequentemente descartam esses cabeçalhos.
  • Várias visões sobre “snapshotting” simples: usar git stash, branches/tags dedicados de WIP, ou ferramentas externas de snapshot.

Segurança e preocupações quânticas

  • A discussão esclarece que:
    • Ataques de extensão de comprimento não são relevantes para o uso de hashes pelo Git.
    • Ameaças quânticas afetam principalmente criptografia assimétrica; cifras simétricas e hashes sofrem, no máximo, uma redução de segurança de raiz quadrada.
  • SHA-256 é considerado suficiente; mudar agora para SHA-3 é visto como impraticável, dado o trabalho de transição de longa duração já realizado.

Diversos

  • Notas sobre GitHub e Bitbucket estarem atrasados no suporte a SHA-256, embora o GitHub supostamente tenha private previews.
  • Interesse em ver o reftable se tornar padrão, além de debates paralelos sobre IDs inteiros de commit (como no Mercurial) e comportamentos de queda do sistema de arquivos afetando refs.