O código-fonte do GitHub vazou no GitHub ontem à noite … mais ou menos
O GitHub não foi realmente comprometido, apesar das aparências em contrário.
Na noite passada, o desenvolvedor e ativista de privacidade Resynth1943 anunciou que o código-fonte do GitHub vazou no próprio GitHub, no próprio repositório DMCA do GitHub . Vai demorar um pouco para falar sobre isso, mas as primeiras coisas primeiro – isso não é tão grande quanto pode parecer.
GitHub Enterprise Server! = GitHub.com
Pouco depois de Resynth1943 – que parece ter dado a notícia e descrito o código como tendo “vazado” por um indivíduo desconhecido – compartilhou novamente o anúncio no Hacker News, o CEO do GitHub, Nat Friedman, apareceu na HN para fornecer algum contexto.
De acordo com Friedman, o upload em questão foi, na verdade, do GitHub Enterprise Server, não do próprio site do GitHub. Embora os dois compartilhem um volume considerável de código, a distinção é significativa. Parte dessa importância é que o próprio GitHub não foi realmente hackeado.
Embora nem o GitHub nem o GitHub Enterprise Server sejam código-fonte aberto, o código-fonte do GitHub Enterprise Server é rotineiramente enviado aos clientes, embora geralmente em um formato simplificado e ofuscado. De acordo com Friedman, o GitHub acidentalmente forneceu a alguns clientes um tarball completo e não ofuscado do GHES alguns meses atrás; este é o código que foi despejado no repositório DMCA público do GitHub.Propaganda
Moendo um machado relacionado ao DMCA
LEITURA ADICIONAL
Parece provável que o “indivíduo desconhecido” Resynth1943 referido carregou o código-fonte vazado em grande parte por raiva sobre a recente remoção do Youtube-dl.
O código em si foi despejado no repositório DMCA do GitHub, que serve como um histórico de solicitações de remoção DMCA que o GitHub recebeu, à medida que as recebe, semelhante aos avisos do Chilling Effects que você pode ter visto nas pesquisas do Google ao longo dos anos.
O que é isso?
Inspirado no Lumen ( anteriormente Chilling Effects ) e no Google , este repositório contém o texto dos avisos de remoção e contra-avisos DMCA que recebemos aqui no GitHub. Nós os publicamos à medida que são recebidos, apenas com as informações de identificação pessoal eliminadas.
O anúncio do Resynth1943 simultaneamente critica a Microsoft como hipócrita por não abrir deliberadamente o código-fonte do GitHub, ao mesmo tempo que sugere que talvez ele seja menos seguro agora que seu código vazou.
Como tiro um falso commit?
O próprio commit foi sinalizado como aparentemente feito pelo usuário Nat —aka Nat Friedman, o atual CEO do GitHub. Muito parecido com o conteúdo do commit, isso é enganoso – o próprio Git, o sistema de controle de versão do código-fonte subjacente ao GitHub, não protege significativamente contra a representação do usuário. O commit em questão não foi rotulado como “verificado”, o que significa que não foi assinado com a chave GPG de Friedman.
Os commits do Git – assim como as mensagens de e-mail – permitem que os usuários coloquem as informações que desejarem nos campos user.name e user.email. Isso torna a falsificação de informações trivial. A menos que o commit seja realmente assinado com uma chave GPG associada a esse endereço de e-mail, não há nenhuma verificação real de que vem de onde diz que deveria.
Isso deixa o problema de como um commit de algum usuário aleatório iria aparecer no repositório DMCA do GitHub em primeiro lugar – mas a resposta lá também não envolve nenhum comprometimento de conta real.
Quando você envia um commit para um repositório Git, você obtém um hash que representa esse commit e pode ser usado para localizá-lo na árvore. O GitHub – parte do qual é o aplicativo da Web que fornece acesso no navegador à estrutura Git subjacente – mantém todos os bifurcações de um repositório Git em um único repositório subjacente, embora geralmente não apareça dessa forma na estrutura da URL.
Use os garfos, Luke
Portanto, para criar a ilusão de que o CEO do GitHub, Nat Friedman, fez um commit para o repositório GitHub DMCA, o indivíduo desconhecido primeiro precisou clonar o repositório DMCA. Depois de criar uma bifurcação no repositório – criando uma cópia na qual eles tinham privilégios para fazer commits – a próxima etapa foi enviar a fonte vazada, falsificando o nome e o endereço de e-mail de Friedman em user.namee user.email.
Isso resultaria em um repositório bifurcado, com o falso commit. Mas ainda não teria parecido muito certo – a URL, afinal, ainda apontaria para o fork e para o nome de usuário e conta reais do invasor no GitHub. Mas, nos bastidores, pai e fork são parte do mesmo repositório no nível Git subjacente. Isso permitiu que o invasor construísse uma URL que faz com que o commit pareça ter sido feito para o repositório principal, não para o fork.
Para completar o engano, o invasor começou com https://github.com/github/dmca, depois anexou tree/$hashao final, onde $hash estava o hash do commit feito em seu próprio fork – e pronto! O resultado foi uma URL que parecia ser um commit, feito pelo CEO Nat Friedman, para o repositório DMCA do GitHub.
O GitHub não foi “hackeado”, mas há muito espaço para melhorias
No lado positivo, não há compromisso real aqui. O código-fonte foi fornecido gratuitamente, se acidentalmente, aos clientes – não foi exfiltrado de um servidor comprometido. Da mesma forma, Friedman não perdeu o controle de sua própria conta e o GitHub não perdeu o controle de seu repositório DMCA. Nas próprias palavras um tanto irreverentes de Friedman no Hacker News, “está tudo bem, a situação normal, a cotovia está voando, o caracol está no espinho e está tudo bem com o mundo”.
Embora todas as travessuras documentadas aqui estejam dentro das expectativas – se você quiser verificar sua identidade, você deve assinar seus commits com uma chave GPG – essas expectativas em si são, talvez, muito mais baixas do que deveriam. Gerenciar GPG ainda é oneroso o suficiente para servir como uma barreira significativa de entrada para muitos desenvolvedores. Mais importante, o GitHub não oferece nenhum controle para enfatizar a presença – ou falta – de tais assinaturas. Vimos muitas sugestões flutuando para dicas de ferramentas como “este usuário normalmente assina seus commits, e este commit não é assinado” quando apropriado. Também achamos que já passou da hora de corrigir o problema, permitindo que um invasor falsifique qual repositório se comprometeu a usar a técnica de construção de URL fork-and-manual que descrevemos acima.
Finalmente, provavelmente é hora de ter uma discussão séria sobre se os commits não assinados devem ser um padrão em primeiro lugar. Vivemos em um mundo onde até mesmo a simples navegação na Web deve ser realizada com o uso de autenticação e criptografia – o que torna o tipo de falsificação casual visto hoje ainda mais surpreendente e perturbador
.
