dragon-lady/push-guardHook Git pre-push locale e scanner del filesystem che rileva probabili fughe di segreti, oscura i valori corrispondenti e blocca i push senza telemetria né accesso alla rete.
Push Guard è una protezione locale Git pre-push per probabili fughe di segreti.
Analizza il contenuto in fase di push, segnala i probabili pattern di segreti, oscura tutti i valori corrispondenti ed esce con codice diverso da zero in modo che Git blocchi il push.
Creato e mantenuto da Dragon Lady - github.com/Dragon-Lady - X: @answerislove2
La versione 0.4.3 rimuove l'eccezione inline # push-guard: ignore. Un aggiornamento può iniziare a bloccare push e pacchetti che in precedenza passavano. Prima di aggiornare hook condivisi o installazioni CI, ispeziona ciascun repository utilizzatore:
git grep -n -i 'push-guard:[[:space:]]*ignore'
Esamina ogni corrispondenza. Rimuovi i segreti e il materiale privato; nessuno dei due può essere esentato.
Per fixture legittime di workflow/IOC, aggiungi solo il percorso esatto del repository
revisionato e gli ID esatti delle regole workflow.* a .push-guard-allow. I marcatori inline ora sono
testo ordinario, inclusi quelli nei test o nella documentazione. Non convertire
automaticamente tutte le righe dei marcatori in esenzioni. Esamina ogni nuova esenzione come una
modifica sensibile alla sicurezza.
L'hook pre-push legge le eccezioni dal commit base pubblicizzato della destinazione, mai dalla copia di lavoro o dai commit candidati. Una nuova o ampliata esenzione deve essere esaminata e stabilita separatamente prima di poter esentare un push successivo. Per un push multi-ref, si applicano solo le eccezioni condivise da ogni base di destinazione. I nuovi ref senza una base pubblicizzata non ricevono eccezioni.
Allo stesso modo scan legge la policy da --base. Quando si verifica un intervallo storico
più ampio rispetto a uno snapshot di policy esaminato separatamente, passa esplicitamente
--allow-list-ref <reviewed-40-character-commit-SHA>. Questa è una decisione di fiducia
esplicita da parte del chiamante; non sostituire mai la policy del candidato non esaminato.
scan-package continua a usare la policy --repo selezionata dal chiamante, al di fuori
dell'artefatto. Fornisci una directory di policy esaminata quando scansioni build non attendibili.
Esegui push-guard scan --base <trusted-base> --head HEAD e
push-guard scan-package dist/* della nuova versione rispetto alle modifiche in uscita effettive e agli
artefatti compilati prima di aggiornare l'hook installato. I percorsi dei membri dell'archivio possono differire
dai percorsi sorgente; esamina quei percorsi esatti separatamente. Mantieni la versione
installata esistente finché i repository interessati non hanno completato questa migrazione.
Landing page pubblica: push-guard.netlify.app
La landing page statica del progetto si trova in docs/ e non ha dipendenze
di runtime, script esterni, analytics o asset remoti. Può essere servita
con GitHub Pages dalla directory docs/ o distribuita su Netlify usando il
file netlify.toml incluso (nessun comando di build; directory di pubblicazione docs).
Il progetto Netlify attuale usa deploy manuali. Un semplice push Git non
aggiorna la pagina pubblica: pubblica il contenuto di docs/ dopo ogni release e
verifica la versione live, l'immagine social e gli header di risposta. Il file docs/_headers
mantiene gli header di sicurezza quando si distribuisce direttamente quella directory.
--send di Sweep abilita
avvisi aggregati verso destinazioni configurate; la guardia Git rimane offline.git solo per leggere i diff dei commit, gli alberi inviati,
i percorsi degli hook configurati e i metadati di ignore. Il punto di ingresso dell'hook esistente è
preservato, con l'ispezione del contenuto grezzo e della cronologia in uscita rafforzata.$HOME, e non esegue processi figli,
incluso Git.$XDG_STATE_HOME/push-guard-sweep/fp.key (predefinito
~/.local/state/push-guard-sweep/fp.key) per fingerprint stabili e non prevedibili.
Questa chiave è l'eccezione esplicita a "nessun dato memorizzato per impostazione predefinita". Non contiene
dati scansionati. La directory di stato ha permessi 0700 e i file vengono creati con 0600.--baseline e --output di Sweep contengono metadati locali redatti;
--send memorizza ricevute di deduplicazione con chiave, mai credenziali o segreti di avviso.Bloccare un push è la risposta di Git all'avviso. Push Guard rimane in sola lettura
e non modifica i file. L'override è disponibile con git push --no-verify
quando è noto che il valore corrispondente non è un segreto.
Il comando push-guard sweep e l'alias push-guard-sweep forniscono la stessa
ispezione locale. Richiedono il Python 3.11 o superiore del pacchetto esistente e non hanno
dipendenze runtime aggiuntive. I test di sviluppo utilizzano l'extra opzionale test
(python -m pip install ".[test]", poi PYTHONPATH=src python -m pytest -q
dalla radice del repository). La release 0.4.0 aggiunge Sweep. La CI installa quell'
extra di sviluppo ed esegue l'intera suite pytest, inclusi i casi
unittest legacy. I test di release vengono eseguiti in un
job separato; quel job non fornisce mai artefatti di distribuzione alla pubblicazione. Il
job di build degli artefatti non installa le dipendenze di test. Sweep non installa
né abilita uno scheduler.
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
Ogni scansione considera anche le posizioni predefinite di cronologia, dotfile, configurazione e log elencate di seguito. --roots modifica le radici di ricerca per .env* e per le inclusioni personalizzate; usa --exclude per restringere gli altri insiemi predefiniti. Ripetuti --include GLOB aggiungono file all'interno delle ricerche delimitate esistenti, e ripetuti --exclude GLOB rimuovono percorsi. I glob corrispondono a basename, percorsi relativi a HOME o percorsi assoluti. Le esclusioni prevalgono; le inclusioni non possono sovrascrivere le esclusioni di sicurezza o i limiti di profondità. ~ negli argomenti di percorso da CLI viene espanso. I percorsi scansionati devono rimanere all'interno di $HOME.