Remover dados confidenciais de um repositório

Se você fizer commit de dados confidenciais em um repositório Git, poderá removê-los do histórico.

Neste artigo

Sobre a remoção de dados confidenciais de um repositório

Ao alterar o histórico do seu repositório usando ferramentas como git filter-repo ou o BFG Repo-Cleaner, é crucial entender as implicações, especialmente em relação com solicitações pull request abertas e dados confidenciais.

A ferramenta git filter-repo e o BFG Repo-Cleaner reescrevem o histórico do repositório, o que altera os SHAs dos commits existentes alterados por você e todos os commits dependentes. Os SHAs de commits alterados podem afetar as solicitações de pull abertas no repositório. Recomendamos mesclar ou fechar todas as solicitações de pull abertas antes de remover arquivos do repositório.

Você pode remover o arquivo do último commit com git rm. Para saber mais sobre como remover um arquivo adicionado com o commit mais recente, confira "Sobre arquivos grandes no GitHub".

Sobre a exposição de dados confidenciais

Este artigo explica como fazer commits com os dados confidenciais inacessíveis por meio de qualquer branch ou tag do seu repositório em sua instância do GitHub Enterprise Server. No entanto, esses commits ainda podem ser acessados em outro lugar:

  • Em quaisquer clones ou forks do seu repositório
  • Diretamente por meio de seus hashes SHA-1 em exibições em cache em GitHub Enterprise Server
  • Por meio de pull requests que façam referência

Não é possível remover dados confidenciais dos clones de outros usuários do seu repositório, mas é possível remover permanentemente as exibições e as referências em cache aos dados confidenciais nas solicitações de pull do GitHub Enterprise Server entrando em contato com o seu administrador do site.

Depois de efetuar push de um commit para o GitHub Enterprise Server, você deverá considerar todos os dados confidenciais no commit comprometido. Se você tiver feito commit de uma senha, deverá alterá-la. Se tiver feito commit de uma chave, gere outra.

Se a confirmação que introduziu os dados confidenciais existir em qualquer fork, ela continuará acessível lá. Você precisará coordenar com os proprietários dos forks, pedindo-lhes para remover os dados confidenciais ou excluir o fork completamente.

Considere essas limitações e desafios ao tomar a decisão de reescrever a história do repositório.

Remover um arquivo do histórico do repositório

Você pode limpar um arquivo do histórico do repositório usando a ferramenta git filter-repo ou a ferramenta de código aberto BFG Repo-Cleaner.

Note

Se dados confidenciais estiverem localizados em um arquivo identificado como binário, você precisará remover o arquivo do histórico, pois não é possível modificá-lo para remover ou substituir os dados.

Usar o BFG

O BFG Repo-Cleaner é uma ferramenta criada e mantida pela comunidade de código aberto. Ele fornece uma alternativa mais rápida e simples ao git filter-repo para remover dados indesejados.

Por exemplo: para remover o arquivo com dados confidenciais sem alterar o commit mais recente, execute:

bfg --delete-files YOUR-FILE-WITH-SENSITIVE-DATA

Para substituir todo o texto listado em passwords.txt em todas as ocorrências no histórico do repositório, execute:

bfg --replace-text passwords.txt

Depois que os dados confidenciais são removidos, você deve fazer push forçado das suas alterações para GitHub Enterprise Server. Fazer push forçado reescreve o histórico do repositório, o que remove dados confidenciais do histórico de commit. Se você fizer push forçado, isso poderá pode sobrescrever commits nos quais outras pessoas basearam o seu trabalho.

git push --force

Confira a documentação do BFG Repo-Cleaner para obter instruções completas de uso e download.

Usando arquivo git filter-repo

Warning

Ao executar git filter-repo após o stash das alterações, você não poderá recuperar as alterações com outros comandos stash. Antes de executar git filter-repo, é recomendado cancelar o stash das alterações feitas. Para cancelar o stash do último conjunto de alterações com stash, execute git stash show -p | git apply -R. Para obter mais informações, confira Ferramentas do Git – Stash e limpeza.

Para ilustrar como o git filter-repo funciona, mostraremos como remover o arquivo que contém dados confidenciais do histórico do repositório e adicioná-lo ao .gitignore para garantir que ele não sofra um novo commit acidental.

  1. Instale a última versão da ferramenta git filter-repo. Você pode instalar o git-filter-repo manualmente ou usando um gerenciador de pacotes. Por exemplo, para instalar a ferramenta com HomeBrew, use o comando brew install.

    brew install git-filter-repo

    Para obter mais informações, confira INSTALL.md no repositório newren/git-filter-repo.

  2. Se você ainda não tem uma cópia local do repositório que contém dados confidenciais no histórico, clone o repositório no computador local.

    $ git clone https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY
> Initialized empty Git repository in /Users/YOUR-FILE-PATH/YOUR-REPOSITORY/.git/
> remote: Counting objects: 1301, done.
> remote: Compressing objects: 100% (769/769), done.
> remote: Total 1301 (delta 724), reused 910 (delta 522)
> Receiving objects: 100% (1301/1301), 164.39 KiB, done.
> Resolving deltas: 100% (724/724), done.

  3. Navegue até o diretório de trabalho do repositório.

    cd YOUR-REPOSITORY

  4. Execute o comando a seguir, substituindo PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA pelo caminho para o arquivo que deseja remover, não apenas o nome do arquivo. Esses argumentos vão:

    • Forçar o Git a processar todo o histórico de cada branch e marca, mas não fazer check-out

    • Remover o arquivo especificado, bem como todos os commits vazios gerados como resultado

    • Remova algumas configurações, como a URL remota, armazenada no arquivo .git/config. É interessante fazer backup desse arquivo antes para que ele possa ser restaurado mais tarde.

    • Substituir as marcas existentes

        $ git filter-repo --invert-paths --path PATH-TO-YOUR-FILE-WITH-SENSITIVE-DATA
  Parsed 197 commits
  New history written in 0.11 seconds; now repacking/cleaning...
  Repacking your repo and cleaning out old unneeded objects
  Enumerating objects: 210, done.
  Counting objects: 100% (210/210), done.
  Delta compression using up to 12 threads
  Compressing objects: 100% (127/127), done.
  Writing objects: 100% (210/210), done.
  Building bitmaps: 100% (48/48), done.
  Total 210 (delta 98), reused 144 (delta 75), pack-reused 0
  Completely finished after 0.64 seconds.

      Important

      Se o arquivo que contém dados confidenciais existia em algum outro caminho (porque foi movido ou renomeado), você também precisa executar esse comando nesses caminhos.

  5. Adicione o arquivo que contém dados confidenciais ao .gitignore para garantir que ele não sofra um novo commit acidental.

    $ echo "YOUR-FILE-WITH-SENSITIVE-DATA" >> .gitignore
$ git add .gitignore
$ git commit -m "Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore"
> [main 051452f] Add YOUR-FILE-WITH-SENSITIVE-DATA to .gitignore
>  1 files changed, 1 insertions(+), 0 deletions(-)

  6. Verifique se você removeu tudo o que queria do histórico do repositório e se foi feito check-out de todos os branches.

  7. A ferramenta git filter-repo removerá automaticamente os itens remotos configurados. Use o comando git remote set-url para restaurar seus itens remotos, substituindo OWNER e REPO pelos detalhes de seu repositório. Para obter mais informações, confira "Gerenciar repositórios remote".

    git remote add origin https://github.com/OWNER/REPOSITORY.git

  8. Quando estiver satisfeito com o estado de seu repositório e tiver definido o item remoto apropriado, execute o envio por push forçado das alterações locais para substituir seu repositório em sua instância do GitHub Enterprise Server, bem como todas as ramificações que você enviou por push. É necessário um push forçado para remover dados confidenciais do seu histórico de commit.

    $ git push origin --force --all
> Counting objects: 1074, done.
> Delta compression using 2 threads.
> Compressing objects: 100% (677/677), done.
> Writing objects: 100% (1058/1058), 148.85 KiB, done.
> Total 1058 (delta 590), reused 602 (delta 378)
> To https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)

  9. Para remover o arquivo confidencial das versões marcadas, você também precisará forçar o push das marcas do Git:

    $ git push origin --force --tags
> Counting objects: 321, done.
> Delta compression using up to 8 threads.
> Compressing objects: 100% (166/166), done.
> Writing objects: 100% (321/321), 331.74 KiB | 0 bytes/s, done.
> Total 321 (delta 124), reused 269 (delta 108)
> To https://HOSTNAME/YOUR-USERNAME/YOUR-REPOSITORY.git
>  + 48dc599...051452f main -> main (forced update)

Remover completamente os dados de GitHub

Depois de usar a ferramenta BFG ou git filter-repo para remover os dados confidenciais e efetuar push das alterações para o GitHub Enterprise Server, você precisa executar mais algumas etapas para remover por completo os dados do GitHub Enterprise Server.

  1. Entre em contato com o seu administrador do site e solicite a remoção de exibições em cache e referências aos dados confidenciais em solicitações de pull no GitHub Enterprise Server. Forneça o nome do repositório e/ou um link para o commit que você precisa remover. Para saber mais sobre como os administradores de site podem remover objetos Git inacessíveis, consulte "Utilitários de linha de comando". Para obter mais informações sobre como os administradores do site podem identificar commits acessíveis, consulte "Identificar commits acessíveis".

  2. Diga aos colaboradores para trocar a base (não fazer a mesclagem) dos branches que eles criaram fora do histórico do repositório antigo (afetado). Um commit de merge poderia reintroduzir o histórico antigo completo (ou parte dele) que você acabou de se dar ao trabalho de corrigir.

  3. Se você usou o git filter-repo, pode pular esta etapa.

    Se você usou a ferramenta BFG, após reescrever, poderá limpar as referências em seu repositório local para o histórico antigo a ser desreferenciado e lixo coletado com os seguintes comandos (usando o Git 1.8.5 ou mais recente):

    $ git reflog expire --expire=now --all
$ git gc --prune=now
> Counting objects: 2437, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (1378/1378), done.
> Writing objects: 100% (2437/2437), done.
> Total 2437 (delta 1461), reused 1802 (delta 1048)

    Note

    Faça isso também enviando por push o histórico filtrado para um repositório novo ou vazio e fazendo um clone novo do GitHub Enterprise Server.

Identificando commits alcançáveis

Para remover totalmente dados indesejados ou confidenciais de um repositório, o commit que introduziu os dados pela primeira vez precisa ter a referência totalmente removida em branches, tags, solicitações de pull e bifurcações. Uma única referência em qualquer lugar impedirá que a coleta de lixo seja capaz de limpar os dados completamente.

Você pode verificar se há referências existentes usando os comandos a seguir quando conectado ao dispositivo via SSH. Você precisará do SHA do commit que originalmente introduziu os dados confidenciais.

ghe-repo OWNER/REPOSITORY -c 'git ref-contains COMMIT_SHA_NUMBER'
ghe-repo OWNER/REPOSITORY -c 'cd ../network.git && git ref-contains COMMIT_SHA_NUMBER'

Se qualquer um desses comandos retornar algum resultado, você precisará remover essas referências antes que a confirmação possa ser coletada como lixo com êxito. O segundo comando identificará as referências que existem nos forks do repositório (se o repositório não tiver bifurcações, você poderá pular a execução).

  • Os resultados que começam com refs/heads/ ou refs/tags/ indicam ramificações e tags, respectivamente, que ainda contêm referências ao commit ofensivo, sugerindo que o repositório modificado não foi totalmente limpo do commit ou que não foi forçado por push.
  • Os resultados que começam com refs/pull/ ou refs/__gh__/pull indicam pull requests que fazem referência à confirmação ofensiva. Essas pull requests precisam ser excluídas para permitir que o commit seja coletado como lixo. Uma solicitação de pull pode ser excluída no painel de administração do site em https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY/PULL_REQUESTS/<PULL-REQUEST-NUMBER> com a substituição de <PULL-REQUEST-NUMBER> pelo número da pull request.

Se forem encontradas referências em qualquer fork, os resultados serão semelhantes, mas começarão com refs/remotes/NWO/. Para identificar o fork pelo nome, você pode executar o comando a seguir.

ghe-nwo NWO

O mesmo procedimento usando a ferramenta BFG ou git filter-repo pode ser usado para remover os dados confidenciais das bifurcações do repositório. Como alternativa, as bifurcações podem ser excluídas completamente e, se necessário, o repositório pode ser bifurcado novamente assim que a limpeza do repositório raiz for concluída.

Depois de remover as referências do commit, execute novamente os comandos para verificar mais uma vez.

Se não houver resultados de nenhum dos comandos ref-contains, você poderá executar a coleta de lixo com o sinalizador --prune para remover os commits não referenciados executando o comando a seguir.

ghe-repo-gc -v --prune OWNER/REPOSITORY

Depois que a coleta de lixo tiver removido o commit com êxito, você desejará navegar até o painel de administração do site do repositório em https://HOSTNAME/stafftools/repositories/OWNER/REPOSITORY, selecionar Rede e clicar em Invalidar cache do Git para remover todos os dados armazenados em cache.

Evitar commits acidentais no futuro

Impedir que colaboradores façam commits acidentais pode ajudar a evitar que informações confidenciais sejam expostas. Para obter mais informações, confira "Melhores práticas para evitar vazamentos de dados na sua organização".

Há alguns truques simples para evitar fazer commit de coisas não desejadas:

  • Use um programa visual como o GitHub Desktop ou o gitk para fazer commit das alterações. Nos programas visuais, geralmente é mais fácil ver exatamente quais arquivos serão adicionados, excluídos e modificados em cada commit.
  • Evite os comandos catch-all git add . e git commit -a na linha de comando: use git add filename e git rm filename para preparar os arquivos individualmente.
  • Use git add --interactive para revisar e preparar alterações individualmente em cada arquivo.
  • Use git diff --cached para revisar as alterações que você preparou para commit. Essa é a comparação exata que git commit produzirá, desde que você não use o sinalizador -a.
  • Habilite a proteção por push para seu repositório para detectar e impedir que envios por push contendo segredos codificados sejam confirmados na sua base de código. Para obter mais informações, confira "Sobre a proteção por push".

Leitura adicional