O Segredo Aberto do GitHub: Seus Repositórios Privados e Excluídos Não São Tão Privados Assim

Em poucas palavras

O jardim do GitHub tem uma erva daninha de privacidade crescendo fora de controle. Acontece que excluir seus forks do GitHub ou até mesmo repositórios inteiros não apaga os dados. Essa informação suculenta permanece pronta para ser coletada, acessível a qualquer pessoa que saiba onde procurar. Estamos falando de chaves de API, informações privadas, o ouro. Isso não é um bug, é um "recurso" e está fazendo algumas pessoas suarem frio. Vamos mergulhar em como isso funciona, por que é um grande problema e o que você pode fazer para proteger seu precioso código.

Rede de Repositórios do GitHub: Uma Teia Emaranhada de Forks e Segredos

O GitHub, o queridinho da colaboração em código aberto, tem um pequeno segredo. Ele gerencia repositórios e seus forks como uma árvore genealógica gigante, com o repositório original como raiz. Parece inocente, certo? Mas aqui está o problema: quando você exclui um repositório público que foi bifurcado, o GitHub não simplesmente destrói a árvore inteira. Em vez disso, ele simplesmente reatribui a raiz para um dos forks sobreviventes. Isso significa que qualquer código submetido ao repositório original, mesmo após um fork, pode ser acessado por meio de qualquer um de seus forks. Sim, você leu certo. Excluído não significa que sumiu, apenas… realocado.

Isso fica ainda mais interessante com repositórios privados. Imagine o seguinte: você inicia um repositório privado para um novo projeto, faz um fork dele para adicionar algum ingrediente secreto que você planeja monetizar e, em seguida, abre o código do repositório original. Você pode presumir que essas submissões privadas permanecem privadas. Bem, surpresa! Quaisquer commits feitos no fork privado antes de você tornar o repositório original público ainda estão visíveis. Adeus ingrediente secreto.

Por que isso Importa: Quando o Código Aberto se Torna um Pouco Aberto Demais

As implicações aqui são enormes. Aquela chave de API que você acidentalmente subiu? Sim, ela ainda pode estar lá fora, mesmo se você excluiu o repositório. Aquela informação privada que você pensou estar guardada em um fork privado? Pense de novo. Se alguém souber onde procurar, poderá encontrá-la. Este não é apenas um problema hipotético. Pesquisadores de segurança já encontraram dados confidenciais, como chaves de API e chaves privadas, apenas vasculhando os repositórios públicos e forks do GitHub. E adivinha? O GitHub sabe disso. Eles até reconhecem isso em sua documentação, chamando-a de "decisão de design intencional".

Agora, antes que você pegue seus forcados, é importante lembrar que o GitHub foi construído sobre os princípios da colaboração em código aberto. Mas há uma diferença entre colaboração aberta e expor dados confidenciais involuntariamente. Este "recurso" parece confundir essa linha, e é um problema.

O Que Você Pode Fazer: Protegendo Seu Código em um Mundo de Forks Persistentes

Então, o que um desenvolvedor deve fazer? Aqui estão algumas dicas para manter em mente:

1. Trate os Repositórios Públicos Como Las Vegas: Presuma que o que Acontece Lá, Permanece Lá

Se você fizer o commit em um repositório público, considere-o público para sempre. Isso inclui repositórios e forks excluídos. Verifique duas, três vezes antes de enviar qualquer coisa confidencial. E se você errar, aja rápido. Altere as chaves de API, remova dados confidenciais e entre em contato com o suporte do GitHub se necessário.

2. Repositórios Privados Não São Infalíveis: Esteja Ciente da Linha do Tempo do Código Aberto

Se você planeja abrir o código de um projeto, esteja ciente do que você envia para forks privados. Quaisquer commits feitos antes que o projeto se torne público podem ser expostos. Considere manter esses recursos super-secretos em um repositório separado, verdadeiramente privado, até que você esteja pronto para liberá-los.

3. GitHub, Precisamos Conversar: Advocar pela Mudança

Este problema não vai desaparecer sozinho. Vamos encorajar o GitHub a repensar esta decisão de design. Podemos começar aumentando a conscientização, enviando feedback e defendendo controles de privacidade mais fortes. Afinal, código aberto não precisa significar sacrificar a segurança.

Conclusão: Um Chamado de Atenção para a Segurança do Código Aberto

Toda essa confusão do GitHub é um chamado de atenção para a comunidade de código aberto. É hora de começar a pensar de forma diferente sobre como lidamos com informações confidenciais. Não vamos deixar a conveniência do código aberto prejudicar nossa segurança e privacidade. Portanto, sigam em frente, colegas desenvolvedores, e codifiquem com responsabilidade. E talvez fiquem de olho nesses forks, nunca se sabe quem pode estar à espreita nos galhos.

Source:

Anyone can Access Deleted and Private Repository Data on GitHub ◆ Truffle Security Co.

You can access data from deleted forks, deleted repositories and even private repositories on GitHub. And it is available forever. This is known by GitHub, and intentionally designed that way.