Re: encrypting python modules
How often do these things *actually* happen? Of those that actually do it, how many are clueless enough that when they run into problems they blame you for it? (And remember that you won't even find out about the non-clueless ones.) This is a rethorical question, right? -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Paul Sijben wrote: The problem: I have a client-server app written in python. I want to make sure that the client is not: 1) destabilized by users accidentally or on purpose dropping python files in the path (after which calling the helpdesk will not be useful) 2) extended with new features without me knowing about it (again resulting in calls to my helpdesk...) You could check the MD5 hashes of your files. robert -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Mike, thanks for the constructive feedback.Indeed i probably need to patch import in some way. Looks like there is no standard way to get this done. So I guess I have do it myself... In the famous last words department: how hard can that be? ;-) Paul Mike Meyer wrote: On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney [EMAIL PROTECTED] wrote: Paul Sijben [EMAIL PROTECTED] writes: I know that I can not stop a dedicated hacker deconstructing my code. A direct consequence of this is that you can not stop *anyone* from deconstructing your code if it's in their possession. It takes only one dedicated, skilled person to crack your obfuscation system and distribute an automated process for doing so to anyone interested. Except that's not what he's trying to do. However I can not imagine that I would be the first one planning to do this. So is there a solution like this available somewhere? Trying to make bits uncopyable and unmodifiable is like trying to make water not wet. And again, that's not what he's trying to do. He wants to arrange things so that he doesn't have to support unmodified versions of his code, by making it impossible to import modified modules. While that's still impossible, once you decide how difficult you want to make it for people to do that, you can *probably* make it that difficult - but the process gets progressively more difficult and expensive as you make it harder. I think he's contemplating only the simplest, least expensive step: adding an import hook that only allows imports of digitally signed modules. If planning to deploy on Windows, where he has to bundle a python with his application, he may well implement the hook in the interpreter instead of in python, so it's harder to find. If you wanted to go to the expense, you could probably arrange things so that the digital signatures are the more vulnerable attack vectors, but I'd expect to spend millions of dollars doing so. mike -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Robert Latest wrote: Paul Sijben wrote: The problem: I have a client-server app written in python. I want to make sure that the client is not: 1) destabilized by users accidentally or on purpose dropping python files in the path (after which calling the helpdesk will not be useful) 2) extended with new features without me knowing about it (again resulting in calls to my helpdesk...) You could check the MD5 hashes of your files. robert indeed but I still need to hook into import to do that reliably, right? -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
On Mon, 14 Jan 2008 09:49:49 +0100, Paul Sijben wrote: How often do these things *actually* happen? Of those that actually do it, how many are clueless enough that when they run into problems they blame you for it? (And remember that you won't even find out about the non-clueless ones.) This is a rethorical question, right? No, it's a serious question. You distribute Python code, and you're worried that your users will modify the source code and then neglect to mention it when they report bugs which they introduced. Before you build an elephant-proof fence around your house, it is quite reasonable to ask whether or not there are actually elephants in your neighbourhood. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Paul Sijben wrote: You could check the MD5 hashes of your files. indeed but I still need to hook into import to do that reliably, right? Depends. In a job I once had I just supplied a shell script that spat out the MD5 sums of my sources. When I got a support request I had the customer run the script and email the result to me so I could check if anything had changed. (A malicious person could of course have stored the good MD5 sums, then done his changes, and then made his request, sending me the old sums.) If your customer is cooperative and trustworthy, this is a good way to find stupid mistakes. If he ain't, drop him ;-) robert -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Steven D'Aprano wrote: No, it's a serious question. You distribute Python code, and you're worried that your users will modify the source code and then neglect to mention it when they report bugs which they introduced. Before you build an elephant-proof fence around your house, it is quite reasonable to ask whether or not there are actually elephants in your neighbourhood. Depending on where you are, there are probably plenty. Recently I started hacking around in a GPLed Python app (GRAMPS, if anybody cares). This program has a built-in bug report feature which makes it easy to email bugs with associated stack trace etc. to the developers. Unfortunately the bug report window also automatically popped up even when stuff went wrong within my own broken code. For such a case it would be good if a software could somehow detect modifications of itself and its associated modules. And, contrary to the advice I gave elsethread, unfortunately it's impossible to just drop uncooperative customers when you develop GPL software ;-) robert -- http://mail.python.org/mailman/listinfo/python-list
RE: encrypting python modules
-Original Message- From: [EMAIL PROTECTED] [mailto:python- [EMAIL PROTECTED] On Behalf Of Paul Sijben Sent: Friday, January 11, 2008 4:45 AM To: python-list@python.org Subject: encrypting python modules The problem: I have a client-server app written in python. I want to make sure that the client is not: 1) destabilized by users accidentally or on purpose dropping python files in the path (after which calling the helpdesk will not be useful) 2) extended with new features without me knowing about it (again resulting in calls to my helpdesk...) Would the site module help with that? It looks like site will let you put your modules first in sys.path. Or what about just updating sys.path as the first action in your program? Or what about pulling clean copies of the files from a tar/zip/archive before execution? A shell script creates a temp dir and extracts the files to the temp dir to run. Not sure it would do any good to pull from an encrypted tar/zip/archive. Or what about pulling the client files from the server instead of a tar/zip/archive...? * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. GA625 -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
On Mon, 14 Jan 2008 12:46:48 +, Robert Latest wrote: And, contrary to the advice I gave elsethread, unfortunately it's impossible to just drop uncooperative customers when you develop GPL software ;-) Just because you are writing GPLed code doesn't mean you are permanently linked to anyone you have supplied code to. You can send their emails straight to /dev/null. You don't have to give them any support, only the source code. And if you do give them support, the GPL doesn't limit what your hourly rates are: you are free to charge them one million dollars per hour, payable in advance in blocks of fifteen hours. If they don't like it, they can always fork the code, or find another person to support it, or simply stop being dicks. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Robert Latest [EMAIL PROTECTED] writes: And, contrary to the advice I gave elsethread, unfortunately it's impossible to just drop uncooperative customers when you develop GPL software ;-) On the contrary. The GPL includes a big fat NO WARRANTY clause. If you're not selling warranties to people, don't provide any more support to them than you want to. The main benefit of software licensed under the GPL is that your customer has the freedom to take the software and get someone else to improve it instead of you. That's good for them *and* good for you, since you *can* drop them if it's to your advantage to do so. -- \ Everything is futile. -- Marvin of Borg | `\ | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
encrypting python modules
Hello, this question has come by repeatedly in several guises over the past years but has never been solved in this forum as far as I have been able to Google. However since so many people are asking the question, I hope someone has made a solution and is willing to share it. The problem: I have a client-server app written in python. I want to make sure that the client is not: 1) destabilized by users accidentally or on purpose dropping python files in the path (after which calling the helpdesk will not be useful) 2) extended with new features without me knowing about it (again resulting in calls to my helpdesk...) 3) trivially decompiled. Added issue, I want the client to be able to update itself when I have fixed bugs or created new functionality. I know that I can not stop a dedicated hacker deconstructing my code. Since all clients need to go through the server I am not afraid of freeloaders. I am now considering overriding import with some code that will only import modules signed and crypted by me. However I can not imagine that I would be the first one planning to do this. So is there a solution like this available somewhere? Paul Sijben -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Paul Sijben [EMAIL PROTECTED] writes: I know that I can not stop a dedicated hacker deconstructing my code. A direct consequence of this is that you can not stop *anyone* from deconstructing your code if it's in their possession. It takes only one dedicated, skilled person to crack your obfuscation system and distribute an automated process for doing so to anyone interested. However I can not imagine that I would be the first one planning to do this. So is there a solution like this available somewhere? Trying to make bits uncopyable and unmodifiable is like trying to make water not wet. -- \ The shortest distance between two points is under | `\ construction. -- Noelie Alito | _o__) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
On Sat, 12 Jan 2008 09:47:26 +1100 Ben Finney [EMAIL PROTECTED] wrote: Paul Sijben [EMAIL PROTECTED] writes: I know that I can not stop a dedicated hacker deconstructing my code. A direct consequence of this is that you can not stop *anyone* from deconstructing your code if it's in their possession. It takes only one dedicated, skilled person to crack your obfuscation system and distribute an automated process for doing so to anyone interested. Except that's not what he's trying to do. However I can not imagine that I would be the first one planning to do this. So is there a solution like this available somewhere? Trying to make bits uncopyable and unmodifiable is like trying to make water not wet. And again, that's not what he's trying to do. He wants to arrange things so that he doesn't have to support unmodified versions of his code, by making it impossible to import modified modules. While that's still impossible, once you decide how difficult you want to make it for people to do that, you can *probably* make it that difficult - but the process gets progressively more difficult and expensive as you make it harder. I think he's contemplating only the simplest, least expensive step: adding an import hook that only allows imports of digitally signed modules. If planning to deploy on Windows, where he has to bundle a python with his application, he may well implement the hook in the interpreter instead of in python, so it's harder to find. If you wanted to go to the expense, you could probably arrange things so that the digital signatures are the more vulnerable attack vectors, but I'd expect to spend millions of dollars doing so. mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
On Fri, 11 Jan 2008 10:44:36 +0100, Paul Sijben wrote: Hello, this question has come by repeatedly in several guises over the past years but has never been solved in this forum as far as I have been able to Google. However since so many people are asking the question, I hope someone has made a solution and is willing to share it. The problem: I have a client-server app written in python. I want to make sure that the client is not: 1) destabilized by users accidentally or on purpose dropping python files in the path (after which calling the helpdesk will not be useful) 2) extended with new features without me knowing about it (again resulting in calls to my helpdesk...) How often do these things *actually* happen? Of those that actually do it, how many are clueless enough that when they run into problems they blame you for it? (And remember that you won't even find out about the non-clueless ones.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote: Trying to make bits uncopyable and unmodifiable is like trying to make water not wet. Certainly not. I can put water into the freezer, but I have no idea how to make bits uncopyable and unmodifiable while still delivering them to the clients for execution. ;-) Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: encrypting python modules
Marc 'BlackJack' Rintsch [EMAIL PROTECTED] writes: On Sat, 12 Jan 2008 09:47:26 +1100, Ben Finney wrote: Trying to make bits uncopyable and unmodifiable is like trying to make water not wet. Certainly not. I can put water into the freezer Turning it into ice, and making it not useable as water. So, to the extent you've made it not-wet, you've also made it not-water. To torture the analogy further, this would be equivalent to engraving the bits in stone and sealing the whole in a concrete slab. While still technically the bits can be extracted, the extent to which they are uncopyable and unmodifiable is exactly the extent to which they are useless as bits. As soon as they become available for use as digital bits in some way, they become available for copying and modifying again. -- \ People demand freedom of speech to make up for the freedom of | `\thought which they avoid. -- Soren Aabye Kierkegaard | _o__) (1813-1855) | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
