Il giorno 16 novembre 2010 13:35, Manlio Perillo <manlio.peri...@gmail.com>ha scritto:
> Il problema però è capire i casi di uso. > In quale casi hai bisogno di verificare l'integrità di tutti i moduli > Python utilizzati? > L'unico caso di uso che mi viene in mente è quando l'interprete python > viene eseguito con privilegi particolare (ad esempio root, oppure > accesso a porte IP). > Penso che sia necessario, oltre ai casi da te citati, nel caso in cui ad esempio Python venga utilizzato come scripting di un altro motore (poniamo l'esempio di un motore grafico, o di una applicazione tanto complessa da rendere necessaria tale scelta). In quel caso, qualora si possa voler preferire un linguaggio già pronto (anzichè fare un nuovo interprete che magari supporti i file binari per proteggere anche la logica), si rende necessario il poter operare in tutta tranquillità in una sandbox, e quindi controllare che non vi siano manomissioni a uno qualunque dei moduli utilizzati (altrimenti si comprometterebbe la stabilità e il flusso di lavoro del programma). Per fare un esempio mi vengono in mente solo applicativi di una certa stazza, che probabilmente, visto il loro valore, non si appoggerebbero mai ad una soluzione che ne esponga la logica. Boh, adesso non saprei precisamente il perchè di una scelta, magari come dici tu è solo perchè da root potrebbe compromettere l'intero sistema, ma se è un software destinato ad uso professionale penso che anche se non venga eseguito da root dovrebbe garantire sempre la corretta esecuzione, pensa se un utente modifica i file python, magari per sbaglio, e poi lavora sul software (poniamo che sia di disegno tecnico), clicca su 'Salva' e si rende conto che il menù File non funziona perchè la relativa funzione python è stata compromessa (e non è rara la scelta di un linguaggio di scripting per gestire l'interfaccia grafica, anzi). Invece controllando, all'avvio, eventualmente segnala che il programma necessita di essere reinstallato e boh. Se ho sbagliato qualcosa, correggetemi pure. Probabilmente ci sono altre motivazioni più valide, ma che non mi vengono in mente. > > Al momento non sono sicuro della differenza tra i due, dovrei leggere il > codice. > Io prevedo di farlo stasera, se ho un po' di tranquillità, nel caso scopro la differenza la posto qui subito. > > [...] > > Unico problema trovato in fase di compilazione del sorgente è che il > > modulo hashlib crea un errore cercando di importare _md5, anche se, > > onestamente, non capisco perchè in fase di compilazione tenti di > > eseguire il modulo signedimporter (che importa hashlib). > > > > Parli della compilazione di python? > Si, dopo aver modificato la '_PyImportHooks_Init' e compilando ottengo quell'errore. Se uso la stessa gestione che usano per zipimport ovvero, in caso di errore passaci sù, funziona giustamente. Però poi anche a runtime ad ogni avvio quella sarebbe la gestione dell'errore. Probabilmente avviene perchè hashlib non ha ancora accesso a tutte le sue dipendenze (magari devono essere compilate). Per provare ho lasciato passare l'errore, la soluzione definitiva sarebbe o fare il modulo in C (come lo è zipimport) o magari trovare un modo per aggirare il problema di hashlib. > > Ciao Manlio > Ciao e buona serata. PS. a questo punto, se dovesse rendersi necessario il fare troppe modifiche all'interprete per via di vari problemi nei moduli, si potrebbe pensare ad includere un nuovo file .c all'interprete e rendere il controllo parte integrante dell'interprete stesso, ovviamente se dovesse essere necessario farlo su *tutti* i moduli, permettendo però, di inserire in qualche modo il dizionario con le chiavi. Però mi suona di cosa che necessita la modifica dell'inizializzazione di CPython, perchè dovrebbe poter accedere ad un dato runtime (il dizionario), prima dell'inizializzazione e quindi dell'esecuzione effettiva del programma: forse la soluzione non è fattibile.
_______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
