A armadilha do selo Verified: assinaturas malleáveis ameaçam a unicidade do hash em commits de Git

Um novo trabalho de investigação de Jacob Ginesin (PhD no Carnegie Mellon e auditor criptográfico em Cure53) desmonta uma suposição estendida: que uma confirmação (commit) assinada em Git é, por si mesma, um nome único e imutável para seu conteúdo. A técnica não quebra SHA-1 nem SHA-256 nem altera o código; aproveita a malleabilidade das assinaturas —formas distintas e válidas de representar a mesma assinatura — para reescrever os bytes da assinatura que se incluem no objeto commit, mudando assim sua hash sem tocar arquivos, autor ou data. Ginesin documenta três vetores concretos (ECDSA, RSA/EdDSA com campos OpenPGP não autenticados e S/MIME com codificações DER não canônicas) e acompanha seu estudo com ferramentas de teste e repositórios demo que mostram como o GitHub continua a estampar o selo "Verified" após essas mutações.

A raiz do problema não é Git nem os humanos que assinam, mas como as forjas consomem e confiam na assinatura: GitHub e outros serviços não normalizam as assinaturas antes de verificar e associam o selo Verified ao hash exato do objeto recebido. Isso permite cenários práticos de exploração: bloquear um commit por sua hash deixa um espaço - um atacante pode voltar a empurrar a mesma confirmação com assinaturas re-encodificadas sob um hash diferente e, ainda assim, ver a marcada como verificada -; sistemas de deduptação, listas de bloqueio e bitácoras de procedência que usam apenas o hash herdarão a mesma fragilidade; um espelho comprometido pode devolver confirmações válidamente assinadas cuja representação em bytes (e, portanto, sua hash) difere da versão no forja canônica.

É importante salientar o que isto não é: não é uma porta para mudar o conteúdo sem que a assinatura o detecte. O conteúdo fílmico de blobs e árvores permanece idêntico, e pinnear um hash completo para obter código continua garantindo que você receberá exatamente aquilo cujo hash corresponde ou falhará a descarga. A questão é semântica e operacional: o selo "Verified" não garante que o hash seja um nome único e imutável do objeto assinado, e muitas ferramentas confiam nessa garantia errada.

A lição prática lembra um precedente bem conhecido em criptografia aplicada: Bitcoin tropeçou com uma simetria de ECDSA que permitia mudar o valor s por n − s e modificar o ID de transação sem a chave privada; a solução foi impor uma forma canônica ("low-S") e, em uma mudança arquitetônica, separar assinaturas da identificação com SegWit. A recomendação equivalente para forjas é óbvia e técnica: canonizar a representação das assinaturas antes de verificar e antes de registrar um selo de confiança. Na prática isso significa aceitar apenas formas canônicas (por exemplo low-S para ECDSA), remover ou normalizar campos não autenticados de OpenPGP e validar/normalizar codificações DER em S/MIME.

O que cada ator deve fazer? Para as forjas (GitHub, GitLab, etc.) a ação é clara e urgente: normalizar as assinaturas antes de as marcar como verificadas, armazenar e voltar a verificar a forma canonizada e invalidar se a assinatura ou a chave deixam de ser canônicas ou são revogadas. Para as ferramentas que bloqueiam por hash, deduplican ou computam rastreabilidade, a recomendação é não fiar do hash bruto de um objeto assinado entrante: verificar a assinatura, canonizá-la e depois computar o identificador a utilizar para bloqueio ou registro, ou alternativamente basear a deduaplicação em vestígios de conteúdo (árbol/blobs) em vez do hash do objeto commit completo.

Para desenvolvedores e consumidores de pacotes ou Actions, a boa notícia é que as práticas recomendadas não mudam de raiz: continuar a desenhar commits completos é correto, e ancorar ainda checksums independentes dos artefatos ou usar sistemas que verificam conteúdo (por exemplo derivações de saída fixa em Nix) acrescenta um respaldo que evita classes inteiras de problemas. No entanto, há um ajuste na vigilância: não se deve usar o selo "Verified" como único critério de segurança para aceitar ou bloquear código; esse selo demonstra quem assinou, não que o hash seja uma identidade única e insobornável.

O trabalho de Ginesin foi reportado a projetos relevantes (Git, GNU e forjas) e, pelo menos no momento de sua publicação, ainda esperava um adesivo difundido. A comunidade dispõe de arranjos conceituais maduros: canonicalizar assinaturas é uma prática conhecida e bem entendida. O primeiro ponto de atenção óbvio é o S/MIME, onde a ferramenta pública reproduz casos que git locais estritos rejeitam, mas que o GitHub aceita como "Verified".

Em suma, estamos perante um problema de confiança operacional, não de integridade de conteúdo: os forjes devem corrigir sua pipeline de verificação para que o badge "Verified" signifique realmente o que os usuários esperam. Entretanto, os responsáveis por infraestrucutra de segurança e fornecimentos devem atualizar sua lógica de bloqueio e deduplicação para validar e canonizar assinaturas antes de confiar no hash, e os desenvolvedores devem continuar a ancorar dependências com hashes completos e, quando possível, com checksums adicionais e mecanismos de verificação de artefatos reprodutíveis.

Para ler o trabalho e os testes publicados por Ginesin, você pode consultar sua lista em arXiv e reproduzir os demos; a busca por autor oferece o documento e materiais associados em aberto: arXiv – busca por Jacob Ginesin. Para entender como o GitHub apresenta e documenta a verificação de assinaturas em commits, sua página oficial de documentação é um ponto de referência útil: GitHub Docs – About commit signature verification. Para verificar localmente assinaturas de commits e ver como git maneja a verificação, a documentação de git sobre git-verify-commit é prática: git-verify-commit.