Trabalhando com a proteção de push via linha de comando

Sobre a proteção de push via linha de comando

A proteção contra push evita que você faça commit de segredos acidentalmente em um repositório ao realizar o bloqueio de envios por pushes que contêm segredos com suporte.

Quando você tenta efetuar push de um segredo compatível via linha de comando para um repositório como a proteção de push habilitada, o GitHub bloqueia o push.

Você deve:

• Remover o segredo do seu branch. Para obter mais informações, consulte Resolver um push bloqueado.
• Seguir uma URL fornecida para ver quais opções estão disponíveis para você a fim de permitir o push. Para obter mais informações, consulte "Ignorando a proteção de push" e Solicitando privilégios de bypass.

Até cinco segredos detectados serão exibidos por vez na linha de comando. Se um segredo específico já tiver sido detectado no repositório e um alerta já existir, o GitHub não bloqueará esse segredo.

Se você confirmar que um segredo é real e que pretende corrigi-lo mais tarde, tente corrigi-lo o mais rápido possível. Por exemplo, você pode revogar o segredo e removê-lo do histórico de commits do repositório. Segredos reais que foram expostos devem ser revogados para evitar acesso não autorizado. Você pode considerar primeiro rotacionar o segredo antes de revogá-lo. Para saber mais, confira Remover dados confidenciais de um repositório.

Resolvendo um push bloqueado

Para resolver um push bloqueado, você deve remover o segredo de todos os commits em que ele aparece.

• Se o segredo foi introduzido pelo seu commit mais recente, consulte Remover um segredo introduzido pelo commit mais recente em seu branch.
• Se o segredo aparecer em commits anteriores, consulte Remover um segredo introduzido por um commit anterior em seu branch.

Remover um segredo introduzido pelo commit mais recente em seu branch

Se o segredo bloqueado tiver sido introduzido pelo commit mais recente em seu branch, você poderá seguir as diretrizes abaixo.

1. Remova o segredo do código.
2. Para fazer commit das alterações, execute git commit --amend --all. Isso atualiza o commit original que introduziu o segredo em vez de criar um novo commit.
3. Efetue o push das alterações com git push.

Remover um segredo introduzido pelo commit anterior em seu branch

Você também poderá remover o segredo se ele aparecer em uma confirmação anterior no histórico do Git. Para fazer isso, você precisará identificar qual commit introduziu o segredo pela primeira vez e modificar o histórico de commit com um trocar base interativo.

1. Examine a mensagem de erro exibida quando você tentou enviar por push sua ramificação, que lista todas as confirmações que contêm o segredo.

   remote:   —— GitHub Personal Access Token ——————————————————————
   remote:    locations:
   remote:      - commit: 8728dbe67
   remote:        path: README.md:4
   remote:      - commit: 03d69e5d3
   remote:        path: README.md:4
   remote:      - commit: 8053f7b27
   remote:        path: README.md:4
   

2. Em seguida, execute git log para ver um histórico completo de todas as confirmações em sua ramificação, juntamente com seus carimbos de data/hora correspondentes.

   test-repo (test-branch)]$ git log
   commit 8053f7b27 (HEAD -> main)
   Author: Octocat <1000+octocat@users.noreply.github.com
   Date:   Tue Jan 30 13:03:37 2024 +0100
   
     my fourth commit message
   
   commit 03d69e5d3
   Author: Octocat <1000+octocat@users.noreply.github.com>
   Date:   Tue Jan 30 13:02:59 2024 +0100
   
     my third commit message
   
   commit 8728dbe67
   Author: Octocat <1000+octocat@users.noreply.github.com
   Date:   Tue Jan 30 13:01:36 2024 +0100
   
     my second commit message
   
   commit 6057cbe51
   Author: Octocat <1000+octocat@users.noreply.github.com
   Date:   Tue Jan 30 12:58:24 2024 +0100
   
     my first commit message
   
   

3. Focusing only on the commits that contain the secret, use the output of git log to identify which commit comes earliest in your Git history.

   • In the example, commit 8728dbe67 was the first commit to contain the secret.

4. Start an interactive rebase with git rebase -i <COMMIT-ID>~1.

   • For <COMMIT-ID>, use the commit identified in step 3. For example, git rebase -i 8728dbe67~1.

5. In the editor, choose to edit the commit identified in step 3 by changing pick to edit on the first line of the text.

   edit 8728dbe67 my second commit message
   pick 03d69e5d3 my third commit message
   pick 8053f7b27 my fourth commit message
   

6. Salve e feche o editor para iniciar o trocar base interativo.

7. Remova o segredo do código.

8. Adicione suas alterações à área de preparo usando git add ..

   Note

   O comando completo é git add ..

   • Há um espaço entre add e ..
   • O ponto após o espaço faz parte do comando.

9. Fazer commit de suas alterações usando git commit --amend.

10. Execute git rebase --continue para concluir a troca de base.

11. Efetue o push das alterações com git push.

Ignorando a proteção de push

Se o GitHub bloquear um segredo que você acredita ser seguro para o envio por push, você pode conseguir ignorar o bloqueio ao especificar um motivo para permitir que o segredo seja enviado por push.

Quando você permite que um segredo seja enviado por push, um alerta será criado na guia Segurança. GitHub fecha o alerta e não envia uma notificação se você especificar que o segredo é um falso positivo ou usado apenas em testes. Se você especificar que o segredo é real e que o corrigirá mais tarde, GitHub manterá o alerta de segurança aberto e enviará notificações ao autor do commit, bem como aos administradores do repositório. Para obter mais informações, confira "Gerenciar alertas da verificação de segredo".

Quando um colaborador ignora um bloco de proteção por push para um segredo, GitHub também envia um alerta de e-mail para os proprietários da organização, gerentes de segurança e administradores de repositório que optaram por receber notificações por e-mail.

Se você não vir a opção para ignorar o bloqueio, isso indicará que o administrador do repositório ou o proprietário da organização configurou controles mais rígidos em relação à proteção contra push. Em vez disso, você deve remover o segredo do commit ou enviar uma solicitação para “ignorar privilégios” a fim de enviar por push o segredo bloqueado. Para obter mais informações, consulte Solicitando privilégios de bypass na documentação do GitHub Enterprise Cloud.

1. Acesse a URL retornada pelo GitHub quando o push foi bloqueado.

2. Escolha a opção que melhor descreve o motivo pelo qual você deve conseguir efetuar push do segredo.

   • Se o segredo for usado apenas em testes e não representar nenhuma ameaça, clique em Ele é usado em testes.
   • Se a cadeia de caracteres detectada não for um segredo, clique em É um falso positivo.
   • Se o segredo for real, mas você pretender corrigi-lo mais tarde, clique em Corrigirei mais tarde.

3. Clique em Permitir que eu efetue push deste segredo.

4. Tente efetuar push novamente na linha de comando em até três horas. Se você não efetuar push em até três horas, precisará repetir esse processo.

Solicitando privilégios de bypass

Se o envio por push foi bloqueado pela proteção contra push e você acredita que o segredo é seguro para ser enviado por push, é possível realizar uma solicitação de permissão para ignorar o bloqueio. A solicitação será enviada a um grupo designado de revisores, os quais realizarão a aprovação ou a negação da solicitação.

As solicitações expiram após sete dias.

1. Acesse a URL retornada pelo GitHub quando o push foi bloqueado.
2. Em "Ou solicitar privilégios para ignorar", adicione um comentário. Por exemplo, você pode explicar por que acredita que o segredo é seguro para envio por push ou fornecer o contexto sobre a solicitação para ignorar o bloqueio.
3. Clique em Enviar solicitação.
4. Verifique suas notificações por email para obter uma resposta à sua solicitação.

Assim que sua solicitação for analisada, você receberá um email notificando a decisão.

Se a solicitação for aprovada, você poderá enviar por push o commit (ou os commits) que contém o segredo para o repositório, bem como commits futuros que contenham o mesmo segredo.

Se a solicitação for negada, você precisará remover o segredo de todos os commits que contêm o segredo antes de realizar o envio por push novamente. Para obter informações sobre como remover um segredo bloqueado, consulte Resolvendo um push bloqueado.

Leitura adicional

• Trabalhar com proteção de push na interface do usuário do GitHub
• Trabalhando com a proteção contra push via API REST