Support for Encrypted Zip as python scripts
There is an interesting suggestion (http://bugs.python.org/issue6749). to add support to run encrypted zip files as python scripts. No doubt this is a useful functionality to have but it would be great to have some comments on whether this can be(or even should be) feasibly added as an inbuilt support. -- Regards Shashank Singh Senior Undergraduate, Department of Computer Science and Engineering Indian Institute of Technology Bombay shashank.sunny.singh@gmail.com http://www.cse.iitb.ac.in/~shashanksingh
On Sun, Aug 23, 2009 at 9:09 AM, Shashank Singh<shashank.sunny.singh@gmail.com> wrote:
There is an interesting suggestion (http://bugs.python.org/issue6749). to add support to run encrypted zip files as python scripts.
No doubt this is a useful functionality to have but it would be great to have some comments on whether this can be(or even should be) feasibly added as an inbuilt support.
MvL already asked for a patch so I suppose that means he thinks it's useful. Personally I've never encountered an encrypted zipfile, so I just have questions: is there a standard encryption algorithm? What is encrypted? The entire file or individual members? How are you supposed to give the password? Also, I suppose there could be (US) export problems with the code, so it would have to be optional (and we might not be able to build it into binaries we distribute from python.org). -- --Guido van Rossum (home page: http://www.python.org/~guido/)
No doubt this is a useful functionality to have but it would be great to have some comments on whether this can be(or even should be) feasibly added as an inbuilt support.
MvL already asked for a patch so I suppose that means he thinks it's useful.
I am actual skeptical that it is implementable in a reasonable way; if implemented, I'd say: why not?
Personally I've never encountered an encrypted zipfile, so I just have questions: is there a standard encryption algorithm?
In principle, yes. There are several aspects of encryption described in http://www.pkware.com/documents/casestudies/APPNOTE.TXT There are several encryption algorithms defined, such as "traditional PKWARE", DES, 3DES, "original RC2", RC4, AES, "corrected RC2", "corrected RC2-64", blowfish, twofish. In the file header general purpose bits , bit 0 indicates "file is encrypted" (which means "traditional PKWARE"), bit 6 indicates "strong encryption" (an additional header then giving details).
What is encrypted? The entire file or individual members?
Traditionally, only individual files. With strong encryption (only?), the central directory can also be encrypted.
How are you supposed to give the password?
In pkzip: interactively. In the import support: this remains to be seen in the patch. I assume people requesting that feature have a plan.
Also, I suppose there could be (US) export problems with the code, so it would have to be optional (and we might not be able to build it into binaries we distribute from python.org).
The zipfile module already supports decryption. I forgot whether we determined that support for decryption only doesn't fall under the export restrictions, or whether we reported the module to the BXA as well. Regards, Martin
On Sun, Aug 23, 2009 at 2:24 PM, "Martin v. Löwis" <martin@v.loewis.de>wrote:
No doubt this is a useful functionality to have but it would be great to have some comments on whether this can be(or even should be) feasibly added as an inbuilt support.
MvL already asked for a patch so I suppose that means he thinks it's useful.
I am actual skeptical that it is implementable in a reasonable way; if implemented, I'd say: why not?
Personally I've never encountered an encrypted zipfile, so I just have questions: is there a standard encryption algorithm?
In principle, yes. There are several aspects of encryption described in
http://www.pkware.com/documents/casestudies/APPNOTE.TXT
There are several encryption algorithms defined, such as "traditional PKWARE", DES, 3DES, "original RC2", RC4, AES, "corrected RC2", "corrected RC2-64", blowfish, twofish.
In the file header general purpose bits , bit 0 indicates "file is encrypted" (which means "traditional PKWARE"), bit 6 indicates "strong encryption" (an additional header then giving details).
What is encrypted? The entire file or individual members?
Traditionally, only individual files. With strong encryption (only?), the central directory can also be encrypted.
How are you supposed to give the password?
In pkzip: interactively. In the import support: this remains to be seen in the patch. I assume people requesting that feature have a plan.
Also, I suppose there could be (US) export problems with the code, so it would have to be optional (and we might not be able to build it into binaries we distribute from python.org).
The zipfile module already supports decryption. I forgot whether we determined that support for decryption only doesn't fall under the export restrictions, or whether we reported the module to the BXA as well.
I doubt you can even classify the zipfile module's "decryption" support as encryption. It is trivially stupid, easily cracked (a 32bit crc based "cipher"). The zipfile module does not support the various later encryption schemes that use actual crypto algorithms. I do not think we should support execution of python scripts or importing of modules from encrypted zips. I do not see a valid use case. -gps
On Sun, Aug 23, 2009 at 5:59 PM, Gregory P. Smith<greg@krypto.org> wrote:
I doubt you can even classify the zipfile module's "decryption" support as encryption. It is trivially stupid, easily cracked (a 32bit crc based "cipher"). The zipfile module does not support the various later encryption schemes that use actual crypto algorithms.
Oops. I guess this is what Martin called "traditional PKWARE". Quite separate from the current thread it might make sense to support the stronger encryption schemes in zipfile.
I do not think we should support execution of python scripts or importing of modules from encrypted zips. I do not see a valid use case.
I am still awaiting a use case too (for running an encrypted script). I notice that the OP hasn't replied yet. Let's give them a chance. (I added Shashank back to the thread just in case.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
-On [20090823 22:10], Guido van Rossum (guido@python.org) wrote:
Also, I suppose there could be (US) export problems with the code, so it would have to be optional (and we might not be able to build it into binaries we distribute from python.org).
For all I know the website and repository are both located @ the XS4All colocation, so how does US export problems apply? It would apply if the box would've been hosted in the USA, but they're not for all I know. It's one of the reasons FreeBSD had their ebones repository located in Zuid Afrika back in the day. Nowadays they can just include all the relevant bits in the repository. So I wonder how applicable the entire US export restriction still is nowadays. In short: I don't think we have much to worry about. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Wisdom is the difference between knowledge and experience...
On Mon, Aug 24, 2009 at 1:54 AM, Jeroen Ruigrok van der Werven<asmodai@in-nomine.org> wrote:
-On [20090823 22:10], Guido van Rossum (guido@python.org) wrote:
Also, I suppose there could be (US) export problems with the code, so it would have to be optional (and we might not be able to build it into binaries we distribute from python.org).
For all I know the website and repository are both located @ the XS4All colocation, so how does US export problems apply? It would apply if the box would've been hosted in the USA, but they're not for all I know.
It's one of the reasons FreeBSD had their ebones repository located in Zuid Afrika back in the day. Nowadays they can just include all the relevant bits in the repository. So I wonder how applicable the entire US export restriction still is nowadays.
In short: I don't think we have much to worry about.
Are you a lawyer? Do you know the legal history of Python distributions and the US export laws? It's not so easy -- for one, the PSF (a US foundation) owns the copyright. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido <at> python.org> writes:
Are you a lawyer? Do you know the legal history of Python distributions and the US export laws? It's not so easy -- for one, the PSF (a US foundation) owns the copyright.
Does it? As far as I understand, the contributor agreement is not a copyright transfer agreement (« PSF understands and agrees that Contributor retains copyright in its Contributions »). Not that it makes the issue easier of course :) Antoine.
On Wed, Aug 26, 2009 at 7:44 AM, Antoine Pitrou<solipsis@pitrou.net> wrote:
Guido van Rossum <guido <at> python.org> writes:
Are you a lawyer? Do you know the legal history of Python distributions and the US export laws? It's not so easy -- for one, the PSF (a US foundation) owns the copyright.
Does it? As far as I understand, the contributor agreement is not a copyright transfer agreement (« PSF understands and agrees that Contributor retains copyright in its Contributions »).
The rights in the individual contributions are retained by the contributor. However the rights in the distributions as a whole are most definitely claimed by the PSF. Read the LICENSE file in the distro. :-)
Not that it makes the issue easier of course :)
Nothing that involves lawyers is ever easy. That's why well-meaning suggestions like "but python.org is outside the US" are so aggravating -- it's so hard to explain why it doesn't work that way. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
"Martin v. Löwis" -
Antoine Pitrou -
Gregory P. Smith -
Guido van Rossum -
Jeroen Ruigrok van der Werven -
Shashank Singh