Como descomprimir arquivos confidenciais do Git

Controle de dano

Então, você acidentalmente cometeu um arquivo confidencial. Vamos chamá-lo .env. Existem duas questões importantes para responder:

• Você enviou o commit para um repositório remoto?
• O repositório remoto é público?

Ainda não empurrado

Se você ainda não empurrou, a situação não é crítica. Você pode retornar a um commit anterior:

git reset HEAD^ --soft

Seus arquivos permanecerão na cópia de trabalho para que você possa corrigir o arquivo / informação sensível. Se você quiser mantenha o commit e apenas remova o arquivo sensível, Faz:

git rm .env --cachedgit commit --amend

Você pode usar o --amend apenas no último commit. Se você conseguiu adicionar um monte de commits além do que, use:

git rebase -i HEAD~{how many commits to go back?}

Isso permitirá que você conserte o commit defeituoso e reproduzirá todos os commits restantes após a correção para que você não os perca.

Já empurrado

Se você fez push, há uma diferença importante entre repositórios públicos e privados.

Se o seu repositório é privado e não há bots ou pessoas em quem você não confie para acessá-lo, você pode facilmente alterar o último commit usando os dois comandos acima.

Se você empurrou um monte de commits para cima do problemático, você ainda pode usar ramo-filtro ou Limpador repo BFG para remove o arquivo confidencial do histórico do git:

git filter-branch --force --index-filter "git rm --cached --ignore-unmatch .env" --prune-empty --tag-name-filter cat -- --all

Mas tenha em mente dois aspectos importantes dessas mudanças:

• Você está realmente mudando a história
  Se houver outras pessoas, outros branches, outros fork, ou open pull requests contando com o estado atual do repositório, você irá quebrá-los. Nesses casos, trate o repositório como se fosse público e evite alterar o histórico.
• Você precisa limpar o cache
  Você sempre precisa entrar em contato com o suporte do seu provedor de armazenamento Git e pedir a eles para limpar o cache do seu repositório. Mesmo que você tenha corrigido o commit problemático ou reescrito o histórico, o commit antigo com o arquivo confidencial permanece no cache. Você precisa saber seu ID para acessá-lo, mas ele ainda estará acessível até que você limpe o cache.

Preciso regenerar as chaves se forem enviadas para um repositório público?

Resumindo, sim. Se o seu repositório for público ou você não achar que é um lugar seguro por qualquer outro motivo, você deve considerar as informações confidenciais comprometidas.

Mesmo se você remover os dados de seu repositório, você não pode fazer nada sobre bots e outros forks do repo. Então, quais são as próximas etapas?

• Desative todas as chaves e / ou senhas
  Faça isso como o primeiro passo. Depois de desativar as chaves, as informações confidenciais se tornam inúteis.
• Ajustar gitignore
  Adicione todos os arquivos sensíveis ao .gitignore para garantir que o git não os rastreie.
• Remova o arquivo confidencial
• Confirme a correção com uma explicação significativa
  Não tente esconder o erro. Outros colaboradores e você em um mês irão apreciar a explicação do que aconteceu e o que este commit corrige.

Melhores práticas ao armazenar dados confidenciais no Git

Para evitar uma situação como essa no futuro, aqui estão algumas dicas sobre como armazenar dados confidenciais:

Mantenha os dados confidenciais no arquivo .env (ou arquivo semelhante em outras plataformas)

Mantenha as chaves de API e outros dados confidenciais em um único arquivo .env. Dessa forma, você não enviará acidentalmente uma nova chave quando o arquivo .env já estiver excluído do git.

Outro grande benefício é que você obtém acesso a todas as chaves usando um global processo variável.

Use chaves de API, se possível

As chaves de API são fáceis de gerar e desativar, se comprometidas. Se possível, use-os e evite usar credenciais / senhas.

Adicione chaves de API à sua ferramenta de construção

Geralmente, as chaves de API são necessárias durante a criação de aplicativos. Ferramentas de construção como o Netlify permitem que você adicione essas chaves nas áreas seguras de sua administração. Essas chaves são injetadas automaticamente em seu aplicativo por meio do global processo variável.

Adicionar arquivo .env ao gitignore

Certifique-se de que o Git não rastreie arquivos contendo informações confidenciais.

Forneça o arquivo .env.template

O arquivo de modelo instrui outros colaboradores a adicionar as chaves de API necessárias sem exigir que leiam documentos longos.

Não mude o histórico no controle remoto

Use isso como uma regra prática. Se você seguiu as regras acima, não será necessário alterar o histórico.

Espero que essas informações tenham ajudado você a se manter seguro. Você tem uma experiência pessoal com descomprometimento ou talvez um bom lição aprendida? Fale comigo no Twitter 🙂