[Python] Criptazione dei file sorgenti per evitare la manomissione

[Marco Giusti]

On Fri, Nov 12, 2010 at 08:55:15PM +0100, lex mlist wrote:
> Sera a tutti.
> 
> Pensavo di incorporare l'interprete di python in un mio progetto C, visto
> che ho bisogno di permettere ad alcuni non-sviluppatori di sviluppare
> facilmente le loro idee.
> La scelta pende totalmente su di me, ero indeciso tra Python e LUA, ma
> sebbene LUA lo conosco solo di vista, mi sembra che python sia più completo,
> almeno in termini di package già pronti (se sbaglio vi prego di
> correggermi).

Non conosco lua, ma so' che lo scopo principale, o uno dei principali, è
proprio quello di funzionare da interprete embedded, quindi dipende dai
tuoi bisogni. Python sicuramente ha una grande community e qua la
quantità di codice è sterminata. Inoltre conoscere bene i propri
strumenti è importare, trovo.

> Avrei però la necessità di produrre per la release del programma un sistema
> di "protezione" per evitare che l'utente possa modificare i sorgenti di
> python e compromettere il flusso di esecuzione del programma. Probabilmente
> la risposta sarebbe "non dovresti usare python", ma scrivere un interprete
> porta via troppo tempo e sinceramente non mi và di usare altri linguaggi
> visto che quasi sempre sono per uno specifico scopo e non general purpose.
> Pensavo di crittare il file con Rijndael e di scrivere quindi su un file
> binario, e a runtime decrittare, e passare il file in memoria "in chiaro"
> all'interpete.

Allora, di fatto anche i binari sono modificabili, quindi se uno vuol
pestarsi i piedi da solo un modo lo trova sempre, inoltre il bytecode
python è distribuibile e binario. Potresti distribuire quello, ma
ho l'impressione che lo scopo finale non sia proprio quello di evitare
pasticci da parte degli utenti, ma non sono affari miei.

> Come sistema pensavo potesse andare (se avete esperienze e volete
> condividerle sono tutt'orecchie), ma poi ho pensato che se uno di questi
> sorgenti include un'altro modulo, sorgerebbero problemi perchè python
> cercerebbe un python ".py" in chiaro e non lo troverebbe.

Quale file python dovrebbe cercare, uno facente parte la libreria
standard oppure consideri il caso in cui l'estenzione sia composta da
più di un file? Credo che il caso in esame sia il secondo (dopotutto è
possibile includere la libreria standard nell'estenzione stessa).

In questa ottica prendi in esame il modulo ``zipimport`` (e il pep
302[1]), costruisci un wrapper che nel momento in cui va' a leggere il
file prima lo decripta. Lavorare con gli archivi zip (o gli egg) credo
che semplificherà un po' le cose.

[1] http://www.python.org/dev/peps/pep-0302/

Comunque in linea di massima si tratta sempre di costruire un import
hook, ma dove salverai la chiave per decifrare i file? Se lo scopo è
scoraggiare un utente a modificare un sorgente python allora la
soluzione migliore è distribuire il bytecode dei sorgenti, se lo scopo è
tenere nascosto il codice sorgente dai curiosi, questo è solo un
placebo.

m.


-- 
Dalle virtù che si esigono in un domestico, l'Eccellenza Vostra conosce molti
padroni degni d'esser servitori?
		-- Pierre Augustin Caron de Beaumarchais