On Tue, Apr 30, 2002 at 05:48:34PM +0200, Pawel Lewicki wrote: | | > Pawel Lewicki writes: | > > ... source code security ... | > > 1. Zope management (I suppose the easiest) | > Do not know what you mean... | | I mean to disable management permissions Yes, but then the customer (root@their_machine) can change the emergency user's password and bypass those permission restrictions. | > > 2. Data.fs (Can you pull the stored objects and browse externally?) | > You could modify "cpickle" to write and read encrypted pickles... | | I there any mature solution? | | > > 3. Secure encryption of external Python modules and methods. | > You could modify Python's "importModule" to handle | > encrypted files. | | The same question as above. For now assume you have this solution, it is mature, I'm your customer and I want to be naughty. (note the key there: "I want to be naughty") I can make a script that runs in your interpreter, imports (via your "encrypted import" hook) your code, then run the decompile function on it and print out the result. The underlying principle is If the instructions for the CPU are available (in some way), a determined person can extract that information and do what they please with it. A _really_ determined person could put a scope on the CPU's contacts and read all the instructions and data travelling between the CPU and the rest of the system and record it on an unencumbered system to rebuild your product. It's the same issue with "copy protected" audio CDs and DVDs. If you give them the data you can not prevent them from having the data. Instead a social solution is needed. (for example the music industry should prosecute copyright violators rather than trying to copy-protect cds) HTH, -D -- It took the computational power of three Commodore 64s to fly to the moon. It takes at least a 486 to run Windows 95. Something is wrong here. GnuPG key : http://dman.ddts.net/~dman/public_key.gpg