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

Conheça suas opções para desbloquear o push via linha de comando para o GitHub se a secret scanning detectar um segredo em suas alterações.

Quem pode usar esse recurso?

Usuários com com acesso para gravação

Neste artigo

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:

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.

Note

  • Se a configuração do Git oferecer suporte a pushes para vários branches e não apenas para o branch atual, o push poderá ser bloqueado devido a referências adicionais e não intencionais serem enviadas por push. Para obter mais informações, confira as opções push.default na documentação do Git.
  • Se secret scanning atingir o tempo limite após o push, GitHub ainda executará uma verificação dos seus commits para segredos após o push.

Resolvendo um push bloqueado

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

Note

Para saber como resolver um commit bloqueado na interface do usuário do GitHub, consulte Trabalhar com proteção de push na interface do usuário do GitHub.

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ê poderá 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.

    Note

    É necessário especificar um motivo para ignorar a proteção por push se o repositório tiver a varredura secreta habilitada.

    Ao enviar por push para um repositório público que não tem a varredura secreta habilitada, você ainda está protegido contra envio acidental de segredos graças à proteção por push para usuários, que está ativadahabilitada por padrão para sua conta de usuário.

    Com a proteção por push para usuários, o GitHub bloqueará automaticamente os envios para repositórios públicos se esses envios contiverem segredos com suporte, mas você não precisará especificar um motivo para permitir o segredo, e GitHub não gerará um alerta. Para obter mais informações, confira "Proteção por push para usuários".

  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.

Leitura adicional