Sobre a proteção por push para secret scanning
O recurso de proteção por push de secret scanning ajuda a evitar vazamentos de segurança examinando os segredos antes de enviar alterações por push para o repositório. Quando você habilita a proteção por push, a secret scanning também verifica os pushes em busca de segredos de alta confiança (aqueles identificados com uma baixa taxa de falsos positivos). A Secret scanning lista todos os segredos detectados para que o autor possa revisar os segredos e removê-los ou, se necessário, permitir que esses segredos sejam enviados por push. Para saber mais sobre segredos e provedores de serviços compatíveis com a proteção por push, confira "Padrões de digitalização de segredo".
Se você confirmar que um segredo é real, precisará remover o segredo do branch, de todos os commits em que ele aparece, antes de efetuar push novamente.
Dica Se o GitHub bloquear um segredo que você acredita ser seguro para push, permita o segredo e especifique o motivo pelo qual ele deve ser permitido. Para saber mais sobre como ignorar a proteção por push para um segredo, confira "Como proteger pushes com a verificação de segredos" e "Como proteger pushes com a verificação de segredos" para a linha de comando e a interface do usuário da Web, respectivamente.
Resolver um push bloqueado na linha de comando
Quando você tentar efetuar push de um segredo compatível para um repositório ou uma organização com a secret scanning como uma proteção por push habilitada, o GitHub bloqueará o push. Você pode remover o segredo do branch ou seguir uma URL fornecida para permitir o push.
Observações:
- Se a configuração do Git der 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.defaultna 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.
Se o segredo bloqueado tiver sido introduzido pelo commit mais recente em seu branch, você poderá seguir as diretrizes abaixo.
- Remova o segredo do código.
- Confirme as alterações usando
git commit --amend. - Efetue o push das alterações com
git push.
Você também poderá remover o segredo se ele aparecer em uma confirmação anterior no histórico do Git.
- Use
git logpara determinar qual commit exibido no erro de push veio primeiro no histórico. - Inicie uma troca de base interativa com
git rebase -i <commit-id>~1.é a ID do commit da etapa 1. - Identifique seu commit para editar alterando
pickparaeditna primeira linha do texto que aparece no editor. - Remova o segredo do código.
- Faça o commit da alteração com
git commit --amend. - Execute
git rebase --continuepara concluir a troca de base.
Resolver um commit bloqueado na interface do usuário da Web
Quando você usa a interface do usuário da Web para tentar fazer commit de um segredo com suporte em um repositório ou uma organização com a verificação de segredo como uma proteção por push habilitada, o GitHub bloqueará o commit.
Você verá uma faixa na parte superior da página com informações sobre a localização do segredo e o segredo também será sublinhado no arquivo para que você possa encontrá-lo facilmente.
Para resolver um commit bloqueado na interface do usuário da Web, você precisará remover o segredo do arquivo ou usar a lista suspensa Proteção contra bypass para permitir o segredo. Para saber mais sobre como ignorar a proteção por push pela interface do usuário da Web, confira "Como proteger pushes com a verificação de segredos".
Se você confirmar que um segredo é real, precisará remover o segredo do arquivo. Depois de remover o segredo, a faixa na parte superior da página será alterada e informará que agora você pode fazer commit das suas alterações.