<div class="gmail_quote">Il giorno 17 novembre 2010 13:43, Manlio Perillo <span dir="ltr"><<a href="mailto:manlio.perillo@gmail.com">manlio.perillo@gmail.com</a>></span> ha scritto:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
</div>Il problema è che stiamo parlando di un programma probabilmente<br>
acquistato da un utente e che molto probabilmente gira sul suo computer.<br>
<br>
Se l'utente vuole fare danni, saranno anche problemi suoi, no? :)<br></blockquote><div>Ahahah, si probabilmente hai perfettamente ragione :D<br>In effetti in certi casi converrebbe lasciar perdere e permettere di far fare all'utente ciò che vuole.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Ed in questo caso secimport non va bene; i moduli dovrebbero essere<br>
criptati.<br></blockquote><div><br>Ed anche questa sarebbe una bella soluzione, magari implementando una modifica a CPython che permetta facilmente di aggiungere moduli che ne modificano il comportamento di import. Ma questa è una cosa che si può fare in seguito, e il code obfuscation (a mo' di PHP) non la trovo affatto una soluzione, oltre che una cosa davvero 'anti-pythonic', e poi sinceramente non sò se sia possibile fare del code obfuscation con python, perchè il massimo che si potrebbe fare è cambiare i nomi delle variabili, ma non (per esempio) splittarlo tutto su una riga (mi sembra di aver visto ';' ma sinceramente non sò quanto permetta). :E<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Questo potrebbe essere un buon motivo; e per risolvere questo problema<br>
non è nemmeno essere paranoici per la sicurezza.<br></blockquote><div>Beh allora la cosa inizia a prendere senso, curiosità a parte :) <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Potrebbe essere questo il problema.<br>
In questo caso devi inizializzare tu hashlib (ma possono succedere<br>
casini se poi il runtime di Python la reinizializza in seguito).<br></blockquote><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> Per provare ho lasciato passare l'errore, la soluzione definitiva<br>
> sarebbe o fare il modulo in C (come lo è zipimport)<br>
<br>
</div>Ma dovrai comunque inizializzare il modulo.<br>
Vedi ad esempio l'API C di cStringIO.<br>
<br>
Per hashlib il modulo da inizializzare è _hashlib (Modules/_hashlib.c);<br>
se questo modulo non può essere importato, allora vengono usati i vari<br>
moduli _md5, _sha e così via.<br>
<br>
Mi strano comunque che ti dia l'errore su _md5, dato che secimport di<br>
default usa sha1.<br>
<br></blockquote><div><br>A me sembra strano che in fase di compilazione tenti già di eseguire i moduli, mi sarei aspettato un simile comportamento solo in fase di inizializzazione dell'interprete, non in fase di compilazione :3<br>
<br>In che modo potrei inizializzare il modulo '.c' se non è stato compilato? <br><br>Riguardo l'algoritmo infatti suona strano anche a me, ma stando all'errore è riferito proprio al file 'hashlib.py' (nei sorgenti sotto la cartella Lib)<br>
e la funzione incriminata che non trova il modulo _md5 è: __get_builtin_constructor(name) (se non ricordo male, vado a memoria adesso che non posso avviare la compilazione), e come dici tu, in caso non trova _hashlib importa gli altri singolarmente.<br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
> [...]<br>
<div class="im"><br>
> PS. a questo punto, se dovesse rendersi necessario il fare troppe<br>
> modifiche all'interprete per via di vari problemi nei moduli, si<br>
> potrebbe pensare ad includere un nuovo file .c all'interprete<br>
<br>
</div>Oppure al tuo programma che wrappa l'interprete.<br></blockquote><div>Anche, si però assieme al programma comunque bisogna distribuire la copia dei sorgenti in Python (per la compilazione, o comunque farla recuperare), perchè deve modificare il comportamento standard di Python. <br>
</div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
> e rendere<br>
> il controllo parte integrante dell'interprete stesso, ovviamente se<br>
> dovesse essere necessario farlo su *tutti* i moduli, permettendo però,<br>
> di inserire in qualche modo il dizionario con le chiavi.<br>
<br>
</div>Vedi lo script build_signature_database.py.<br>
Lo si può modificare per fargli generare codice C che definisca il<br>
dizionario.<br>
<br>
Prima di fare questo, però hai bisogno di una instanza di CPython<br>
"pulita" per creare il dizionario.<br></blockquote><div><br>Ottima idea quella dello script. La necessità di avere una copia "pulita" di CPython non penso sia uno svantaggio, proprio perchè almeno ciò che deve fare lo sviluppatore (generare il dizionario) in questo modo lo può fare in Python.<br>
E poi, tolto Windows, sia Linux, che BSD che Mac OS X (non mi ricordo di preciso su quest'ultimo, perchè gli ho subito installato XCode e dipendenze varie) hanno Python di default.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
Ciao Manlio<br></div></blockquote><div>A scanso di equivoci, ho scritto dall'ufficio, accanto ad una segretaria un "poco" chiacchierona, quindi potrei non aver rappresentato correttamente i miei pensieri e/o potrei essere stato deviato dal discorso originario con qualche affare di tipo burocratico/economico :E<br>
<br>Ciao e buona serata.<br></div></div>