Forjando commits assinados no GitHub
O uso, pelo GitHub, de um parser baseado em regex para metadados de commits permitiu um exploit que forjou commits assinados com “verificação do GitHub” ao dessicronizar a forma como o Git e o GitHub interpretavam o campo author. Os comentaristas argumentam que isso exemplifica os riscos de parsing ad hoc e de incompatibilidades entre parsers em código sensível à segurança, e muitos pedem o uso das próprias bibliotecas do Git ou de parsers mais rígidos e orientados por especificação. O incidente também alimenta um ceticismo mais amplo sobre o valor de segurança de commits assinados, assinaturas gerenciadas pelo GitHub e processos de triagem de bugs que inicialmente minimizam esses relatos.
Causa-raiz: Regex vs. parsing correto
- Muitos comentaristas veem isso como um exemplo clássico de “não faça parse de formatos estruturados com regex ad hoc”, especialmente em código crítico para segurança.
- Outros enfatizam que o problema mais profundo é um descompasso entre parsers: a lógica de regex personalizada do GitHub e o parser do próprio Git discordam sobre o que é válido, permitindo ataques de dessincronização.
- Vários argumentam que a única opção verdadeiramente segura é reutilizar a própria implementação do Git (ou libgit2), e não reimplementar o parsing.
- Alguns defendem regex se usada em verificações pequenas, bem delimitadas e em várias etapas (por exemplo, primeiro localizar linhas
author, depois validar estritamente o formato e falhar diante de qualquer coisa estranha).
Especificação, validação e a lei de Postel
- Comentaristas criticam a correção como “apenas ajustar a regex”, em vez de especificar corretamente o formato do cabeçalho do commit e aplicá-lo com um parser rígido.
- O padrão mais seguro sugerido: falhar rapidamente diante de múltiplas linhas
author, linhas malformadas ou qualquer coisa inesperada. - O princípio da robustez de Postel (“seja liberal no que aceitar”) é fortemente criticado por ser incompatível com a segurança moderna; parsing permissivo transforma entradas ruins de outras pessoas em seu problema.
- Outros observam que a lei de Postel historicamente ajudou na interoperabilidade inicial da Internet, mas hoje é perigosa para componentes sensíveis à segurança.
Significado e valor dos commits assinados pelo GitHub
- Alguns tratam “assinado pela assinatura verificada do GitHub” como equivalente a não assinado, já que não é a própria chave do autor.
- Outros veem valor: isso atesta que o commit veio pela interface web do GitHub ou pelo Codespaces sob uma conta autenticada, e fornece um timestamp confiável—útil em alguns cenários de cadeia de suprimentos e backdating, assumindo que o GitHub não esteja comprometido.
- Há confusão e irritação com o GitHub reescrevendo o committer para si mesmo para anexar o selo verificado; críticos veem isso como poluição dos metadados do Git, enquanto apoiadores dizem que isso se encaixa no modelo author/committer (a ferramenta ou o mantenedor agindo em nome do autor).
- Usar uma única chave de assinatura para todos os usuários é visto como algo que aumenta o raio de explosão de bugs como este.
Commits assinados: utilidade e dor prática
- Alguns dizem que commits assinados são em grande parte inúteis: se atacantes conseguem enviar código, muitas vezes também conseguem assiná-lo.
- Outros enfatizam seu papel na mitigação de riscos de cadeia de suprimentos, mas apenas se a confiança na chave for significativa (web of trust do PGP, chaves servidas por domínio ou chaves hospedadas pela plataforma).
- A configuração e as ferramentas são vistas como trabalhosas, embora a assinatura baseada em SSH e integrações com gerenciadores de senha sejam mencionadas como formas de facilitar o processo.
- Há consenso de que endpoints de assinatura cegos (como o Codespaces assinando commits arbitrários) aumentam drasticamente a complexidade e a superfície de ataque.
Processo de segurança e transparência
- Vários comentários criticam a triagem de vulnerabilidades do GitHub (e de grandes empresas): muito ruído de relatórios de baixa qualidade leva funcionários juniores a encerrar problemas reais como “não é um bug”.
- Anedotas destacam organizações descartando achados sérios como “comportamento intencional” até que reguladores ou exposição pública se envolvam.
- Alguns observam como preocupante o padrão do GitHub de encerrar rapidamente questões de segurança e a falta de um pós-mortem público detalhado (inclusive se o bug alguma vez foi explorado).