This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: Support for encrypted zipfiles when interpreting zipfile as script
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
Status: closed Resolution: wont fix
Dependencies: Superseder:
Assigned To: Nosy List: gregory.p.smith, jcea, loewis, manis, ncoghlan
Priority: normal Keywords:

Created on 2009-08-21 04:51 by manis, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (10)
msg91800 - (view) Author: Peter Manis (manis) Date: 2009-08-21 04:51
The zipfile support in 2.6 that allows you pass a zipfile(with 
inside) as the "script", does not support encrypted zipfiles.  I view this 
as being a feature that could be useful to some.
msg91803 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2009-08-21 06:37
Can you provide a patch?
msg91893 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2009-08-23 21:17
Some (supportive) discussion on python-dev at .
msg91896 - (view) Author: Peter Manis (manis) Date: 2009-08-23 23:46
I don't think I will be able to provide a patch.  If I am correct this 
would live in Modules/zipimport.c and I do not have enough experience in 
C/C++ to add in the feature.  If in the end zipimport ends up using 
Lib/ then I can work on adding the feature.
msg91897 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-08-24 01:05
The decryption provided by the zipfile module is for the worthless
32-bit crc based "encryption" of zipfiles.  I think promoting the use of
that is a bad idea.

zipfile can be used by people to get their data out of such files.  We
should not encourage them to put it and/or their code into such a stupid

-1 on supporting this.

Anyways as to implementation details, yes you'd need a way to accept a
key on the command line (or prompt for it using getpass?) and pass it to
the import mechanism at import time.  For zip files with only the
contained file data "encrypted" (the only thing the zipfile module
supports) a zip file could be checked for and .py files
without decrypting first so that a password is only prompted for when
such a module is imported.

Again I don't see value in that.
msg91899 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2009-08-24 02:01
You would also run in to the usual problems with any form of DRM: the
password *will* exist in memory in order for zipimport to be able to use
it, so anyone that really wants the password will be able to get hold of it.

It also isn't as simple as just providing a single password - there can
be multiple zip files on sys.path, so how is Python meant to know which
password goes with which zipfile?

Another -1 here.
msg91901 - (view) Author: Peter Manis (manis) Date: 2009-08-24 02:26
My thinking behind this was not to be the ultimate security against 
someone getting the source, but more of a very high wall to keep out the 
majority of people.

It seems like the best way to determine what file should be decrypted 
and when a password should be prompted is to look at the header of the 
zip file where it defines the encryption information as the zip file is 
loaded.  Taking that approach would allow someone, if they wanted, to 
put multiple encrypted zip files in the path and be prompted for each 
one.  That is not my planned usage of it, but someone else may have a 
use for that.

Could someone point me in the right direction on where this 
functionality would live if implemented?  In the event there is enough 
votes to prevent it from being added I would like to try to work on it 
so I can patch my own installations of Python.
msg91938 - (view) Author: Gregory P. Smith (gregory.p.smith) * (Python committer) Date: 2009-08-24 20:56
The people who do not know how to get over that wall would be equally
stumped if presented with tokenized .pyc or .pyo files.  No fake
encryption needed.
msg95426 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2009-11-18 12:18
A few pointers in case anyone decides to follow this up further:

Zipfile execution is just a special case of normal zipimport: the
zipfile's name is placed at the head of sys.path and a (very) rough
equivalent of "import __main__" is then invoked.

So for zipfile execution to support password protected zipfiles, general
zipimport would need to support them as well.

However, this runs into the problem that invocation of the zipimport
module is largely implicit - the import engine invokes sys.path_hooks
entries (which includes ZipImporter automatically) for a given sys.path
entry and finds that, sure enough, ZipImporter recognises it and creates
an appropriate object to handle it.

So the trick lies in getting the password to the importer that needs to
know it in order to open the zipfile.

For the general case, you could create a new path hook that had a list
of filename pattern<->password pairs that could be placed in
sys.path_hooks ahead of the normal zipimport hook. If it saw a pattern
it recognised, it could use the appropriate password to open the zipfile
and return a corresponding importer object (you could do this largely
independently of the standard library itself - PEP 302 is expressly
designed to let third party developers run with this kind of idea).

That wouldn't help much with zipfile execution though, as you still
wouldn't have a mechanism for providing the password on the command line.
msg168646 - (view) Author: Nick Coghlan (ncoghlan) * (Python committer) Date: 2012-08-20 11:42
Rejecting - if anyone really wants this. they can do it as their own custom import hook.
Date User Action Args
2022-04-11 14:56:52adminsetgithub: 50998
2012-08-20 11:42:53ncoghlansetstatus: open -> closed
resolution: wont fix
messages: + msg168646

stage: resolved
2010-07-11 01:54:37terry.reedysetversions: - Python 2.6, Python 3.0, Python 3.1, Python 2.7
2010-03-24 13:52:48jceasetnosy: + jcea
2009-11-18 12:18:32ncoghlansetmessages: + msg95426
2009-08-24 20:56:49gregory.p.smithsetmessages: + msg91938
2009-08-24 02:26:02manissetmessages: + msg91901
2009-08-24 02:01:56ncoghlansetnosy: + ncoghlan
messages: + msg91899
2009-08-24 01:05:31gregory.p.smithsetnosy: + gregory.p.smith
messages: + msg91897
2009-08-23 23:46:38manissetmessages: + msg91896
2009-08-23 21:19:17gvanrossumsetnosy: - gvanrossum
2009-08-23 21:17:28gvanrossumsetnosy: + gvanrossum
messages: + msg91893
2009-08-21 06:37:22loewissetnosy: + loewis
messages: + msg91803
2009-08-21 04:51:41maniscreate