[issue10030] Patch for zip decryption speedup
Robert de Vries added the comment: Attached you will find the updated patch for the python 3 tree as of now. I have measured a speed-up of more than a factor 100. -- nosy: +rhdv Added file: http://bugs.python.org/file27867/zipdecrypt-3.patch ___ Python tracker <http://bugs.python.org/issue10030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10030] Patch for zip decryption speedup
Robert de Vries added the comment: Patch for python 2.7 Same patch as for python 3, backported to python 2.7 Tested on Linux only. -- Added file: http://bugs.python.org/file27868/zipdecrypt-2.7.patch ___ Python tracker <http://bugs.python.org/issue10030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10030] Patch for zip decryption speedup
Robert de Vries added the comment: My use case is decrypting files of 100's of megabytes. This is so slow that it is quite useless. About an hour or so. I do agree that the encryption is worthless, but that is not important for my use case where I want to discourage people from reverse engineering the contents. If it is so dangerous as some people have pointed out, it should be removed at the cost of not supporting a standard feature of ZIP files. In my opinion you either support a feature and you support it good (efficient) or you don't. As it stands now, users will be disappointed in using a supported feature. Some people argue that adding C code to Python is dangerous as it will lead to bugs, vulnerabilities etc. You could dismiss every addition with C code to Python with this argument, so there must be some positive aspects to outweigh the negative side. The negative side is fairly small (50 lines of very simple C code), plus some standard Python glue code. The benefit is a 100 fold increase in performance and the removal of 1 line of documentation telling that this feature is extremely slow. (patch attached) -- Added file: http://bugs.python.org/file27881/doc.patch ___ Python tracker <http://bugs.python.org/issue10030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10030] Patch for zip decryption speedup
Robert de Vries added the comment: If the encryption is so horrible why is there any support (with bad performance) at all in Python? It would be better to remove it altogether. This prevents users from building software using this feature only to find out later how bad the performance is. (This is the main reason why I have submitted this patch.) If the support had not been in Python I would not have used this feature to begin with. To reiterate my previous point. Either support something and do it well, or don't. Don't do a half job. Please note that there are more attempts to fix this, so I am not completely alone here. http://pypi.python.org/pypi/czipfile -- ___ Python tracker <http://bugs.python.org/issue10030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10030] Patch for zip decryption speedup
Robert de Vries added the comment: The current situation is now that the decryption is part of Python. It is well known to be computationally intensive and should therefore be implemented in C. This patch provides that support. The discussion if Python should support the decryption is behind us, as the support is already in. The only discussion should be about if there are enough users wanting this performance improvement to add it. >From the download statistics of czipfile I would say that there are roughly >2500 users interested. -- ___ Python tracker <http://bugs.python.org/issue10030> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
