Skip to main content

Working with push protection from the command line

Learn your options for unblocking your push from the command line to GitHub if secret scanning detects a secret in your changes.

Quem pode usar esse recurso?

Usuários com com acesso para gravação

Resolving a blocked push

To resolve a blocked push, you must remove the secret from all of the commits it appears in.

Removing a secret introduced by the latest commit on your branch

  1. Remove the secret from your code.
  2. To commit the changes, run git commit --amend --all. This updates the original commit that introduced the secret instead of creating a new commit.
  3. Push your changes with git push.

Removing a secret introduced by an earlier commit on your branch

  1. Examine the error message that displayed when you tried to push your branch, which lists all of the commits that contain the secret.

    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. Next, run git log to see a full history of all the commits on your branch, along with their corresponding timestamps.

    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. Save and close the editor to start the interactive rebase.

  7. Remove the secret from your code.

  8. Add your changes to the staging area using git add ..

    Observação

    The full command is git add .:

    • There is a space between add and ..
    • The period following the space is part of the command.
  9. Commit your changes using git commit --amend.

  10. Run git rebase --continue to finish the rebase.

  11. Push your changes with git push.

Bypassing push protection

Observação

If you don't see the option to bypass a block, you should remove the secret from the commit, or submit a request for "bypass privileges" in order to push the blocked secret. See Requesting bypass privileges.

  1. Visite a URL que GitHub retorna quando o push foi bloqueado, pois o mesmo usuário que executou o push. Se um usuário diferente tentar visitar essa URL, ele receberá um erro 404.

  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.

    Observação

    É 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 saber mais, confira Gerenciando a proteção por push para usuários.

  3. Click Allow me to push this secret.

  4. Reattempt the push on the command line within three hours. If you have not pushed within three hours, you will need to repeat this process.

Requesting bypass privileges

  1. Visite a URL que GitHub retorna quando o push foi bloqueado, pois o mesmo usuário que executou o push. Se um usuário diferente tentar visitar essa URL, ele receberá um erro 404.

  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.

    • If your request is approved, you can push the commit (or commits) containing the secret to the repository, as well as any future commits that contain the same secret.
    • If your request is denied, you need to remove the secret from all commits before pushing again. For information on how to remove a blocked secret, see Resolving a blocked push.

Further reading