Codice Sorgente di "Violent Python" per Python 3

Codice sorgente per il libro "Violent Python" di TJ O'Connor. Il codice è stato completamente convertito a Python 3, riformattato per conformarsi agli standard PEP8 e rifattorizzato per eliminare problemi di dipendenza derivanti dall'implementazione di librerie deprecate.

Una conversione simile a questa è stata resa disponibile da me sul codice sorgente del libro "Black Hat Python" di Justin Seitz. Dai un'occhiata qui se non l'hai ancora fatto.

Utilizzo

Crea semplicemente una nuova directory (DIR) per il progetto, crea un nuovo ambiente virtuale o venv (consigliato), clona questo repository usando git clone e installa i requisiti usando pip install.

user@host:~/DIR$ git clone https://github.com/EONRaider/violent-python3
user@host:~/DIR$ python3 -m venv venv
user@host:~/DIR$ source venv/bin/activate
(venv) user@host:~/DIR$ pip install -r requirements.txt

Note

• Le directory e i file sono stati nominati in modo tale da essere facilmente correlati al contenuto presentato in ogni capitolo.
• Il frequente uso di concatenazione di stringhe da parte dell'autore è stato sostituito con l'interpolazione di stringhe per consentire una maggiore leggibilità e conformarsi a uno standard più moderno.
• I nomi di file, variabili, funzioni, classi e metodi ora sono conformi agli standard di denominazione PEP 8.
• La libreria optparse, ora deprecata, è stata sostituita con argparse in tutto il codice sorgente. Tutto il parsing degli argomenti ora è contenuto nell'ambito di esecuzione __main__ per ogni file. Tutti gli argomenti CLI che erano obbligatori per l'esecuzione degli script ma erano trattati come opzionali nel codice originale sono ora implementati come posizionali. Un prompt di usage è ora disponibile per tutti gli script che usano argparse fornendo l'argomento -h alla CLI. Lasciare le responsabilità sia di boundary che di controller al parser CLI non è certamente la scelta migliore in termini di architettura software, ma è stato lasciato così per la necessità di conformarsi all'intento del programmatore originale.
• Tutte le occorrenze di violazioni PEP 8: E722 do not use bare except sono state rifattorizzate con clausole di eccezione più specifiche.
• L'autore ha l'abitudine di aprire file/database e lasciarli in questo stato invece di chiamare il metodo close() sugli oggetti file/database aperti. Per questo motivo tutte le istanze di manipolazione di file e database sono state rifattorizzate utilizzando context manager.
• L'uso di commenti che fanno riferimento alla codifica da utilizzare da parte dell'interprete (cioè # -*- coding: utf-8 -*-) è stato eliminato a causa della standardizzazione di UTF-8 come codifica predefinita per Python 3 (in sostituzione di ASCII da Python 2).

Refactoring

I file non elencati di seguito possono essere considerati rifattorizzati in un modo o nell'altro come stabilito nella sezione "Note".

• chapter01/vuln_scanner.py era strutturato in modo tale che un file inesistente portasse a un'eccezione OSError in fase di esecuzione. Per questo motivo il controllo dell'iterazione che chiama check_vulns() è stato spostato nell'istruzione condizionale definita nella funzione principale.
• chapter02/nmap_scan.py implementava una funzione principale unicamente allo scopo di chiamare la libreria deprecata optparse, che è stata sostituita da argparse. Per questo motivo la funzione principale è stata rimossa. Una struttura di controllo dell'iterazione che faceva parte della chiamata a optparse nel codice originale era implementata in modo tale che una nuova chiamata a nmap veniva eseguita per ogni porta scansionata. L'iterazione è stata spostata nella funzione nmap_scan per evitare spreco di cicli.
• chapter02/ssh_command.py ha visto il suo codice di inizializzazione spostato nell'ambito di esecuzione __main__. I nomi delle variabili utilizzate nell'ambito esterno che entravano in conflitto con i nomi dei parametri delle funzioni sono stati modificati. Le informazioni del prompt di ritorno erano originariamente codificate e ora sono state decodificate per offrire una migliore leggibilità.

Traduzioni

I contributi in altre lingue possono essere consultati qui:

• Tradotto in Turco da Bedirhan Budak

Contribuire

Per buon senso, prova prima a discutere il cambiamento che desideri apportare a questo repository tramite un ticket (issue).

1. Assicurati che le modifiche che intendi introdurre portino effettivamente a una pull request. La modifica di una o due righe dovrebbe essere richiesta invece tramite un ticket (issue).
2. Se necessario, aggiorna il file README.md con i dettagli relativi alle modifiche alla struttura del progetto.
3. Assicurati che i messaggi di commit che includono le modifiche seguano uno standard. Se non sai come procedere, qui c'è un'ottima referenza su come farlo.
4. La tua richiesta sarà esaminata il prima possibile (di solito entro 48 ore).