Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/16 Enrico Franchi enrico.fran...@gmail.com: On Nov 13, 2010, at 12:23 PM, lex mlist wrote: Scusate, partito per errore. Avevo gia' risposto. -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Grazie sia a Daniele che a Marco per le risposte :) Non mi devo preoccupare di hacking sui sorgenti, tanto gira e rigira un modo chi è determinato lo trova sempre, e poi dovrei fare anche l'obfuscation del codice macchina prodotto dalla compilazione in C, e non mi serve. Penso che l'idea di distribuire il solo bytecode sia sufficiente, l'importante è tamponare l'utente che vede il file di testo e pensa di guardarlo/modificarlo senza sapere quel che stà facendo. Ho già provato a includere l'interprete di Python e non mi sembra una cosa affatto difficile! Ci sono proprio tutti gli strumenti necessari, io mi stò studiando un po' l'architettura di python per interesse personale, ma trovo che anche senza saperne un tubo sia fattibile scrivere con le Python C/API. (e quindi immagino che Lua sia davvero semplice da incorporare) Il giorno 13 novembre 2010 01:04, Daniele Varrazzo p...@develer.com ha scritto: PyInstaller fornisce anche supporto per creare un unico bundle che contiene sia l'eseguibile che i .pyc delle librerie che servono (e i .so/.dll). Probabilmente è facile modificarlo per fargli creare un bundle con l'eseguibile che vuoi tu invece dell'interprete Python., magari lo fa già... Ciao! Gli darò un'occhiata, grazie per la segnalazione! Vediamo un po' cosa riesco a fare... questo Python mi piace sempre di più =)) ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Sat, 2010-11-13 at 01:04 +0100, Daniele Varrazzo wrote: Basta che distribuisci solo i file .pyc invece dei .py: quelli sono sufficienti ad eseguire il programma e vengono trovati dall'import. Questo non è criptare, ma sembra quello che ti serve: è una protezione sufficiente per evitare tampering da parte di chi non è *veramente* motivato e che sappia leggere il bytecode. Direi che basta motivazione sufficiente a spendere 5 minuti per una ricerchina: http://sourceforge.net/projects/unpyc/ Se le pretese sono minori invece basta il modulo dis: def test(a): ... print a ... test(23) 23 import dis dis.dis(test) 2 0 LOAD_FAST0 (a) 3 PRINT_ITEM 4 PRINT_NEWLINE 5 LOAD_CONST 0 (None) 8 RETURN_VALUE Quest'ultimo però in sola lettura, mentre con unpyc si può fare un intero ciclo decompila-modifica-ricompila. Paolo signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Beh, sperando che rimanga cosi... supporta solo python 2.5 e python2.6, io mi stò già appoggiando a Python3 direttamente. Lo sò che non è una soluzione al problema unpyc che prima o dopo ci arriverà (magari già è in sviluppo), comunque ripeto, non è che ci sia da difendere chissà che in termini di proprietà intellettuale, una eventuale decompilazione non espone a rischi di natura pecuniaria, ma dovrebbe servire semplicemente da dissuasore per le modifiche, poi se qualcuno ha voglia di farsi tutto quello, beh... Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? oppure un programma python è destinato a rimanere open source!? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Sat, 2010-11-13 at 12:23 +0100, lex mlist wrote: Beh, sperando che rimanga cosi... supporta solo python 2.5 e python2.6, io mi stò già appoggiando a Python3 direttamente. Lo sò che non è una soluzione al problema unpyc che prima o dopo ci arriverà (magari già è in sviluppo), comunque ripeto, non è che ci sia da difendere chissà che in termini di proprietà intellettuale, una eventuale decompilazione non espone a rischi di natura pecuniaria, ma dovrebbe servire semplicemente da dissuasore per le modifiche, poi se qualcuno ha voglia di farsi tutto quello, beh... Ben detto! Un ragionamento di questo tipo (costi/benefici) è proprio quello che devi fare. Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? oppure un programma python è destinato a rimanere open source!? L'alternativa più sicura, come detto (mi pare) in questo thread, è avere la parte più significativa del programma lato server. Tuttavia devi sempre valutare i costi e i benefici della scelta; da quanto ho capito nel tuo caso distribuire i file pyc, magari inclusi in un qualche eseguibile, dll o quant'altro, è più che sufficiente. Paolo signature.asc Description: This is a digitally signed message part ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/13 lex mlist lexml...@gmail.com: Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? Dai un'occhiata anche a questo vecchio thread http://lists.python.it/pipermail/python/2009-June/006900.html Ciao -- M. http://twitter.com/maxpippi :: http://masci.wordpress.com http://www.pypg.org ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 12:32, Paolo Bernardi villa.lo...@tiscali.it ha scritto: Ben detto! Un ragionamento di questo tipo (costi/benefici) è proprio quello che devi fare. =)) beh sono contento ogni tanto di far qualcosa nel senso giusto :D Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? oppure un programma python è destinato a rimanere open source!? L'alternativa più sicura, come detto (mi pare) in questo thread, è avere la parte più significativa del programma lato server. Tuttavia devi sempre valutare i costi e i benefici della scelta; da quanto ho capito nel tuo caso distribuire i file pyc, magari inclusi in un qualche eseguibile, dll o quant'altro, è più che sufficiente. Si nel mio caso và più che bene la soluzione .pyc, però mi piace conoscere le cose sia per possibiltà future che per innata curiosità :) Tanto per, proverò comunque qualcosa di tipo client-server perchè mi interessa davvero molto. 2010/11/13 Massimiliano Pippi mpi...@gmail.com Dai un'occhiata anche a questo vecchio thread http://lists.python.it/pipermail/python/2009-June/006900.html Grazie, me lo leggo subito :) Ciao Ciao, e grazie di nuovo a tutti! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Nov 13, 2010, at 12:23 PM, lex mlist wrote: Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? oppure un programma python è destinato a rimanere open source!? Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non vuole dire essere open source. -enrico ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 14:24, Enrico Franchi enrico.fran...@gmail.comha scritto: On Nov 13, 2010, at 12:23 PM, lex mlist wrote: Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? oppure un programma python è destinato a rimanere open source!? Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non vuole dire essere open source. Uhm solitamente si tende a confondere open source con freeware, io non intendo dicendo open source che deve essere gratuito, sia chiaro, intendo proprio quello che vuol dire ovvero a sorgenti aperti (visibili), perchè ritieni che l'abbia usato impropriamente? ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 12/11/2010 20:55, lex mlist ha scritto: 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). 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. In casi come questo, invece che criptare/nascondere potresti firmare crittograficamente i vari moduli. Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkzenxUACgkQscQJ24LbaUQZjQCffPaNunLymscCJ6tG+olNh0Cd vQ8AoIZHaHHhRnjV0F4cjx73Q/wUfShe =f9XW -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/13 lex mlist lexml...@gmail.com: Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non vuole dire essere open source. Uhm solitamente si tende a confondere open source con freeware, io non intendo dicendo open source che deve essere gratuito, sia chiaro, intendo proprio quello che vuol dire ovvero a sorgenti aperti (visibili), perchè ritieni che l'abbia usato impropriamente? Perche' so cosa vuole dire open source. La prima riga della definizione dice chiaramente che quello che tu chiamo open source non e' open source. Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: da: http://www.opensource.org/osd.html Poi se vuoi vedere i criteri, sono dentro la pagina. ;) -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
2010/11/13 lex mlist lexml...@gmail.com: Comunque, visto che ritieni la soluzione .pyc (giustamente) facilmente decompilabile, hai quindi una qualche alternativa? oppure un programma python è destinato a rimanere open source!? Open source vuole dire una cosa ben precisa. Avere i sorgenti in mano non vuole dire essere open source. Uhm solitamente si tende a confondere open source con freeware, io non intendo dicendo open source che deve essere gratuito, sia chiaro, intendo proprio quello che vuol dire ovvero a sorgenti aperti (visibili), perchè ritieni che l'abbia usato impropriamente? Perche' so cosa vuole dire open source. Se ti leggi la definizione, e' piuttosto banale vedere che hai errato: Open source doesn't just mean access to the source code. The distribution terms of open-source software must comply with the following criteria: Il resto continua qui: http://www.opensource.org/osd.html -- . ..: -enrico- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On 11/12/2010 09:36 PM, lex mlist wrote: Esattamente che cosa intendi con lua è molto più parco di risorse? che è pensato per girare con meno risorse: l'interprete pesa circa 100kb Uhm, in termini pratici il programma a runtime dovrebbe prendere attraverso la rete i file (.py) necessari e leggerli? no. se la cosa ha senso, e solo tu come creatore del programma lo sai, potresti fare una cosa del genere: quando hai bisogno di elaborare i dati, li mandi al server che poi li restituisce al client. In pratica esponi un'api rest. Ovvio questo non ha sempre senso, dipende anche dal contesto del programma. Beh diciamo che il mio fine ultimo è quello di evitare i .py modificabili con la criptazione per evitare che un semplice editor hex possa permettere di leggerlo. Se poi l'utente ha voglia di farsi del reverse engineering, studiarsi il flusso del programma e generare dei file alternativi, beh la vedo dura, perchè davvero dovrebbe conoscere la chiave di crittazione, dovrebbe sapere ogni file .py quali funzioni deve esporre e tante altre variabili, e poi non mi preoccupo certo di quel livello, alla fine il gioco non ne vale la candela. ok, allora ti basta questo http://bitbucket.org/ubernostrum/django-funserver/src/tip/funserver/management/commands/funserver.py :D -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Il 13/11/2010 17:23, lex mlist ha scritto: Il giorno 13 novembre 2010 15:22, Manlio Perillo manlio.peri...@gmail.com mailto:manlio.peri...@gmail.com ha scritto: In casi come questo, invece che criptare/nascondere potresti firmare crittograficamente i vari moduli. Intendi che dovrei ricavare l'hash del file originale e compararlo con il file che vad ad eseguire per accertarmi che non ci siano manomissioni? Si. Un semplice hash (SHA1, SHAbits e simili) oppure una firma tramite cifratura a chiave pubblica. Se è questo, l'idea è geniale! Non ci avevo pensato mai prima d'ora. Tieni conto che è comunque suscettibile di attacchi, dato che devi memorizzare le firme da qualche parte. Se il core è in C, la manomissione è difficile ma non impossibile (credo, non ho esperienze a riguardo). La parte tecnicamente più complessa è verificare l'hash. Una idea è farlo al momento in cui avviene l'import di un modulo; per questo prova a dare una occhiata al modulo ihooks (non documentato, devi leggere il codice). Oppure dai una occhiata a http://www.python.org/dev/peps/pep-0302/ La cosa non è comunque banale; magari se trovi una soluzione condividila! Ciao Manlio -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkze4HYACgkQscQJ24LbaUQS4gCgi1qVShPCaFuRqeAv4FrkbaaW HxcAoI9QJky0q19j/ff9WPBznozX3mse =X5yG -END PGP SIGNATURE- ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 13 novembre 2010 20:01, Manlio Perillo manlio.peri...@gmail.comha scritto: Si. Un semplice hash (SHA1, SHAbits e simili) oppure una firma tramite cifratura a chiave pubblica. Tieni conto che è comunque suscettibile di attacchi, dato che devi memorizzare le firme da qualche parte. Se il core è in C, la manomissione è difficile ma non impossibile (credo, non ho esperienze a riguardo). Si magari si trova qualcosa di alternativo, comunque è veramente una cosa difficile, ma penso che usando opportune tecniche di obfuscation del codice si riesca a mettere in difficoltà qualsiasi strumento di disassembling, persino del calibro di Ida (ovviamente parliamo di opcode), se ti potrebbe interessare (in caso contrario puoi tranquillamente ignorare): opaque predicates, junky bytes, e altri piccoli trucchetti come punti di ritorno falsi, e altri giochini in assembly puro che permettono davvero di complicare il lavoro a chiunque (anche se in termini assolutistici non saprei dire in quale percentual, sebbene approssimativa al nullo, possa essere fattibile il reverse engineering anche con tali condizioni. Ovviamente l'intera lista comunque va a complicare il codice sorgente e non poco :s quindi direi non proprio nello stile di python :)) La parte tecnicamente più complessa è verificare l'hash. Una idea è farlo al momento in cui avviene l'import di un modulo; per questo prova a dare una occhiata al modulo ihooks (non documentato, devi leggere il codice). Si ci avevo pensato, ma non ero a conoscenza di questi strumenti. Io avevo pensato di modificare eventualmente l'interprete di CPython, aggiungendo in caso di import le relative funzioni per operare sul modulo da importare e poi ritornare al flusso standard del programma. La cosa è fattibile e per altro segna una svolta decisiva contro gli strumenti già pronti per la decompilazione dei file sorgenti criptati. Purtroppo (o non) si va a sacrificare l'interprete CPython standard perchè il programma deve essere eseguito dalla versione modificata dell'interprete. Oppure dai una occhiata a http://www.python.org/dev/peps/pep-0302/ Banale non lo è di certo, diciamo che la trovo comunque molto interessante, sinceramente pensavo ci fossero già buoni progetti in corso di realizzazione in questo senso, ma mi sembra che siano più i decompilatori pyc pyo che i compilatori per proteggere il programma. La cosa non è comunque banale; magari se trovi una soluzione condividila! Ovviamente, sono in debito con la comunità per quanto state condividendo con me, e comunque anche per piacere personale, se troverò qualche soluzione sarete i primi ad essere informati :) Ciao Manlio Ciao e buona serata! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On 11/12/2010 08:55 PM, 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). Ni, py ha molte più librerie pronte, lua è molto più parco di risorse e molto più semplice da includere in un programma c. Dipende dagli usi (molti giochi usano lua e non python per implementare la logica) 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. ... Avete da proporre qualche soluzione/workaround per questo problema? Vuoi essere sicuro che nessuno che abbia voglia di decifrare il programma per farne quello che vuole? Semplice! Non distribuire il programma! Sinceramente. Non distribuirlo. Fallo client-server, sposta la logica in rete. Se invece non vuoi/puoi, se vuoi semplicemente evitare che un appena appena intraprendere hakaro giochi con i tuoi file, prendili e compilali dentro un file c, e falli caricare dall'interprete. -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele dot salmaso at gmail dot com | ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
Il giorno 12 novembre 2010 21:11, Raffaele Salmaso raffaele.salm...@gmail.com ha scritto: Ni, py ha molte più librerie pronte, lua è molto più parco di risorse e molto più semplice da includere in un programma c. Dipende dagli usi (molti giochi usano lua e non python per implementare la logica) Si infatti sono a conoscenza del fatto che molti videogame usino lua, e non solo i videogame, per questo l'avevo messo tra le possibiltà. Esattamente che cosa intendi con lua è molto più parco di risorse? Sinceramente. Non distribuirlo. Fallo client-server, sposta la logica in rete. Uhm, in termini pratici il programma a runtime dovrebbe prendere attraverso la rete i file (.py) necessari e leggerli? Se invece non vuoi/puoi, se vuoi semplicemente evitare che un appena appena intraprendere hakaro giochi con i tuoi file, prendili e compilali dentro un file c, e falli caricare dall'interprete. Beh diciamo che il mio fine ultimo è quello di evitare i .py modificabili con la criptazione per evitare che un semplice editor hex possa permettere di leggerlo. Se poi l'utente ha voglia di farsi del reverse engineering, studiarsi il flusso del programma e generare dei file alternativi, beh la vedo dura, perchè davvero dovrebbe conoscere la chiave di crittazione, dovrebbe sapere ogni file .py quali funzioni deve esporre e tante altre variabili, e poi non mi preoccupo certo di quel livello, alla fine il gioco non ne vale la candela. Grazie mille per la tua risposta, ciao! ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
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 ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
Re: [Python] Criptazione dei file sorgenti per evitare la manomissione
On Fri, 12 Nov 2010 20:55:15 +0100, lex mlist lexml...@gmail.com 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). Sì. Forse Lua è più facile da embeddare (Python non è troppo difficile comunque). Ma hai il vantaggio di una libreria molto più sostanziosa, come hai visto. 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. Basta che distribuisci solo i file .pyc invece dei .py: quelli sono sufficienti ad eseguire il programma e vengono trovati dall'import. Questo non è criptare, ma sembra quello che ti serve: è una protezione sufficiente per evitare tampering da parte di chi non è *veramente* motivato e che sappia leggere il bytecode. PyInstaller fornisce anche supporto per creare un unico bundle che contiene sia l'eseguibile che i .pyc delle librerie che servono (e i .so/.dll). Probabilmente è facile modificarlo per fargli creare un bundle con l'eseguibile che vuoi tu invece dell'interprete Python., magari lo fa già... Ciao! -- Daniele Varrazzo - Develer S.r.l. http://www.develer.com ___ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
