dragon-lady/push-guardHook local de pré-push do Git e scanner de sistema de arquivos que detecta prováveis vazamentos de segredos, redige os valores correspondentes e bloqueia pushes sem telemetria ou acesso à rede.
Push Guard é uma proteção local de pre-push do Git para prováveis vazamentos de segredos.
Ele verifica o conteúdo que está sendo enviado, relata padrões prováveis de segredos, oculta todos os valores correspondentes e encerra com código diferente de zero para que o Git bloqueie o push.
Criado e mantido por Dragon Lady - github.com/Dragon-Lady - X: @answerislove2
A versão 0.4.3 remove a exceção inline # push-guard: ignore. Uma atualização pode começar a bloquear pushes e pacotes que antes passavam. Antes de atualizar hooks compartilhados ou instalações de CI, inspecione cada repositório consumidor:
git grep -n -i 'push-guard:[[:space:]]*ignore'
Revise cada correspondência. Remova segredos e material privado; nenhum dos dois pode ser isento.
Para fixtures legítimas de workflow/IOC, adicione apenas o caminho exato do repositório revisado e os IDs exatos de regra workflow.* ao .push-guard-allow. Marcadores inline agora são texto comum, incluindo os presentes em testes ou documentação. Não converta automaticamente todas as linhas de marcador em permissões. Revise qualquer nova permissão como uma alteração sensível à segurança.
O hook de pré-push lê exceções a partir do commit base anunciado pelo destino, nunca da cópia de trabalho ou dos commits candidatos. Uma permissão nova ou ampliada deve ser revisada e estabelecida separadamente antes de poder isentar um push posterior. Para um push multi-ref, apenas as exceções compartilhadas por todas as bases de destino se aplicam. Refs novas sem uma base anunciada não recebem exceções.
scan da mesma forma lê a política de --base. Ao auditar um intervalo histórico maior contra um snapshot de política revisado separadamente, passe explicitamente --allow-list-ref <reviewed-40-character-commit-SHA>. Esta é uma decisão de confiança explícita do chamador; nunca substitua pela política do candidato não revisado. scan-package continua a usar a política --repo selecionada pelo chamador, fora do artefato. Forneça um diretório de política revisado ao escanear builds não confiáveis.
Execute push-guard scan --base <trusted-base> --head HEAD e push-guard scan-package dist/* da nova versão contra as alterações de saída reais e os artefatos construídos antes de atualizar o hook instalado. Os caminhos de membros de arquivo podem diferir dos caminhos de origem; revise esses caminhos exatos separadamente. Mantenha a versão instalada existente até que os repositórios afetados tenham concluído esta migração.
Página de destino pública: push-guard.netlify.app
A página de destino estática do projeto fica em docs/ e não possui dependências de runtime, scripts externos, analytics ou recursos remotos. Ela pode ser servida com GitHub Pages a partir do diretório docs/ ou implantada no Netlify usando o netlify.toml incluído (sem comando de build; diretório de publicação docs).
O projeto Netlify atual usa implantações manuais. Um push Git sozinho não atualiza a página pública: publique o conteúdo de docs/ após cada release e verifique a versão ao vivo, a imagem social e os cabeçalhos de resposta. O arquivo docs/_headers mantém os cabeçalhos de segurança ao implantar esse diretório diretamente.
--send do Sweep habilita alertas agregados para destinos configurados; o guarda Git permanece offline.git apenas para ler diffs de commit, árvores enviadas, caminhos de hook configurados e metadados de ignore. O ponto de entrada do hook existente é preservado, com a inspeção de conteúdo bruto e histórico de saída reforçada.$HOME, e não executa processos filhos, incluindo Git.$XDG_STATE_HOME/push-guard-sweep/fp.key (padrão ~/.local/state/push-guard-sweep/fp.key) para impressões digitais estáveis e não adivinháveis. Esta chave é a exceção explícita à regra "nenhum dado armazenado por padrão". Ela não contém dados escaneados. O diretório de estado tem permissão 0700 e os arquivos são criados com 0600.--baseline e --output do Sweep contêm metadados locais redigidos; --send armazena recibos de deduplicação com chave, nunca credenciais de alerta ou segredos.Bloquear um push é a resposta do Git ao aviso. O Push Guard permanece somente leitura e não modifica arquivos. A substituição está disponível com git push --no-verify quando o valor correspondido não for um segredo conhecido.
O comando push-guard sweep e o alias push-guard-sweep fornecem a mesma inspeção
local. Eles exigem o Python 3.11 ou superior do pacote existente e não têm
dependências de runtime adicionais. Os testes de desenvolvimento usam o extra opcional test
(python -m pip install ".[test]", depois PYTHONPATH=src python -m pytest -q
a partir da raiz do repositório). A versão 0.4.0 adiciona o Sweep. O CI instala esse
extra de desenvolvimento e executa toda a suíte pytest, incluindo os casos legados
de unittest. Os testes de release são executados em um
job separado; esse job nunca fornece artefatos de distribuição para publicação. O
job de build de artefatos não instala dependências de teste. O Sweep não instala
nem habilita um agendador.
push-guard sweep --list-targets
push-guard sweep --roots ~/projects --class stray
push-guard-sweep --format json --output ~/sweep-report.json
push-guard-sweep --baseline ~/sweep-baseline.json
push-guard-sweep report --format html --output ~/sweep-report.html
push-guard-sweep print-timer --interval 7d
Cada varredura também considera os locais padrão de histórico, dotfiles, configuração e logs abaixo. --roots altera as raízes de busca de .env* e de inclusões personalizadas; use --exclude para restringir os outros conjuntos padrão. --include GLOB repetido adiciona arquivos dentro das buscas limitadas existentes, e --exclude GLOB repetido remove caminhos. Os globs correspondem a basenames, caminhos relativos a HOME ou caminhos absolutos. As exclusões prevalecem; as inclusões não podem sobrepor exclusões de segurança ou limites de profundidade. ~ em argumentos de caminho na CLI é expandido. Os caminhos varridos devem permanecer dentro de $HOME.
.lesshst. O texto do histórico do shell do SQLite é separado dos arquivos de banco de dados..bashrc, .zshrc, .profile, .bash_profile, .npmrc e .docker/config.json; arquivos selecionados JSON, TOML, YAML, INI e CONF sob .config com no máximo quatro níveis de diretório abaixo dele..env*: sob as raízes selecionadas (HOME por padrão), no máximo seis níveis de diretório. Árvores de dependências, ambientes virtuais, metadados do Git e caches são excluídos desta busca..log e arquivos dentro de logs/, no máximo quatro níveis de diretório sob .local/state, .cache, .codex, .config/Cursor/logs e log_dirs configurados.