On Sun, 30 Aug 2009 06:55:33 pm Martin v. Löwis wrote:

...

Does it sound worthy enough to create a patch for and integrate into python itself?

Probably not, given that people think that the algorithm itself is fairly useless.

I would think that for most people, the threat model isn't "the CIA is reading my files" but "my little brother or nosey co-worker is reading my files", and for that, zip encryption with a good password is probably perfectly adequate. E.g. OpenOffice uses it for password-protected documents. Given that Python already supports ZIP decryption (as it should), are there any reasons to prefer the current pure-Python implementation over a faster version? -- Steven D'Aprano

just to give you an idea of the speed up: a 3.3 mb zip file extracted using the current all-python implementation on my machine (win xp 1.67Ghz 1.5GB) takes approximately 38 seconds. the same file when extracted using c implementation takes 0.4 seconds. --shashank On Sun, Aug 30, 2009 at 6:35 PM, wrote:

On 12:59 pm, steve@pearwood.info wrote:

...

On Sun, 30 Aug 2009 06:55:33 pm Martin v. Löwis wrote:

...

...

Does it sound worthy enough to create a patch for and integrate into python itself?

Probably not, given that people think that the algorithm itself is fairly useless.

I would think that for most people, the threat model isn't "the CIA is reading my files" but "my little brother or nosey co-worker is reading my files", and for that, zip encryption with a good password is probably perfectly adequate. E.g. OpenOffice uses it for password-protected documents.

Given that Python already supports ZIP decryption (as it should), are there any reasons to prefer the current pure-Python implementation over a faster version?

Given that the use case is "protect my biology homework from my little brother", how fast does the implementation really need to be? Is speeding it up from 0.1 seconds to 0.001 seconds worth the potential new problems that come with more C code (more code to maintain, less portability to other runtimes, potential for interpreter crashes or even arbitrary code execution vulnerabilities from specially crafted files)?

Jean-Paul

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/shashank.sunny.singh%40gma...

On Sun, Aug 30, 2009 at 7:34 AM, Shashank Singh wrote:

just to give you an idea of the speed up:

a 3.3 mb zip file extracted using the current all-python implementation on my machine (win xp 1.67Ghz 1.5GB) takes approximately 38 seconds.

the same file when extracted using c implementation takes 0.4 seconds.

Are there any applications/frameworks which have zip files on their critical path, where this kind of (admittedly impressive) speedup would be beneficial? What was the motivation for writing the C version? Collin Winter

On Sun, Aug 30, 2009 at 6:35 PM, wrote:

...

On 12:59 pm, steve@pearwood.info wrote:

...

On Sun, 30 Aug 2009 06:55:33 pm Martin v. Löwis wrote:

...

...

Does it sound worthy enough to create a patch for and integrate into python itself?

Probably not, given that people think that the algorithm itself is fairly useless.

I would think that for most people, the threat model isn't "the CIA is reading my files" but "my little brother or nosey co-worker is reading my files", and for that, zip encryption with a good password is probably perfectly adequate. E.g. OpenOffice uses it for password-protected documents.

Given that Python already supports ZIP decryption (as it should), are there any reasons to prefer the current pure-Python implementation over a faster version?

Given that the use case is "protect my biology homework from my little brother", how fast does the implementation really need to be?  Is speeding it up from 0.1 seconds to 0.001 seconds worth the potential new problems that come with more C code (more code to maintain, less portability to other runtimes, potential for interpreter crashes or even arbitrary code execution vulnerabilities from specially crafted files)?

Jean-Paul

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/shashank.sunny.singh%40gma...

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/collinw%40gmail.com

On Sun, Aug 30, 2009 at 10:40 PM, Jeroen Ruigrok van der Werven < asmodai@in-nomine.org> wrote:

-On [20090831 06:29], Collin Winter (collinw@gmail.com) wrote:

...

Are there any applications/frameworks which have zip files on their critical path, where this kind of (admittedly impressive) speedup would be beneficial? What was the motivation for writing the C version?

Would zipped eggs count? For example, SQLAlchemy runs in the 5 MB range.

Unless someone's also pushing for being able to import and execute code from scrambled zip files, no that doesn't matter. The C code for this should be trivially tiny. See the zipfile._ZipDecryptor class, its got ~25 lines of actual code in it. It is not worth arguing about. I'll commit this if you post it as a patch in a tracker issue. Please make sure your patch includes the following: * A unittest that compares the C version of the descrambler to the python version of the descrambler using a variety of inputs and outputs that exercise any boundary condition. * Conditional import code in the zipfile module itself so that the module works even if the C module isn't available. -Greg

exarkun@twistedmatrix.com wrote:

Given that the use case is "protect my biology homework from my little brother", how fast does the implementation really need to be? Is speeding it up from 0.1 seconds to 0.001 seconds worth the potential new problems that come with more C code (more code to maintain, less portability to other runtimes, potential for interpreter crashes or even arbitrary code execution vulnerabilities from specially crafted files)?

Also, if the use case is just protecting stuff from a sibling or your childen, use an archiving program to zip/extract it :) So -1 here as well. Any added C code has a real cost for the reasons Jean-Paul listed, so it should only be used in cases where there's a major practical benefit to the speed-up. Faster execution of a problematic algorithm that is already well implemented by plenty of other applications doesn't qualify in my book (even if the speedup is by a couple of orders of magnitude). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------