[Python-Dev] Support for Encrypted Zip as python scripts

Guido van Rossum guido at python.org
Mon Aug 24 04:41:22 CEST 2009


OMG, the use case is actually running a script without giving the user
access to the script's source? Agreed that's a big -1.

I thought it was just for running a zip containing code so secret you
don't want to leave it around on your hard drive without encryption
(say, the program you use to compute your employee's bonuses, or
perhaps a patented algoritm for detecting spam). That use case would
make a small amount of sense, though I personally don't care enough to
write the code to support it.

--Guido

On Sun, Aug 23, 2009 at 7:09 PM, Nick Coghlan<ncoghlan at gmail.com> wrote:
> Guido van Rossum wrote:
>> Anyway it looks like if someone wants to try this, only the code in
>> runpy.py needs to be touched.
>
> The necessary work would actually be in zipimport. runpy doesn't know
> anything about the details of where the module code comes from, it just
> asks the relevant importer for the details. For zipfile and directory
> execution, they get added to the start of sys.path and then runpy is
> invoked to look for the module "__main__". From that point on most of
> the heavy lifting is handled by the regular import machinery (aside from
> using the pkgutil emulation for the basic import behaviour that isn't
> fully exposed by the imp module).
>
> I added a -1 to the tracker issue as well. That's due both to my opinion
> on the inherent idiocy of DRM though (since shared secrets don't provide
> any security when the attacker in your threat model is one of the people
> you are sharing the secret with) and to the fact that associating
> passwords with the relevant zipfile entries on sys.path would get messy
> fairly quickly.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)


More information about the Python-Dev mailing list