[issue14315] zipfile.ZipFile() unable to open zip File with a short extra header

Serhiy Storchaka added the comment: Just for information: the padding in APK files is added by the zipalign utility [1]. [1] https://developer.android.com/studio/command-line/zipalign -- ___ Python tracker ___

[issue14315] zipfile.ZipFile() unable to open zip File with a short extra header

Gregory P. Smith added the comment: This was never an enhancement. zipfile was failing to properly deal with real world data that other zip file tools on the planet were perfectly happy to deal with. That's a bug. Fixed. Practicality beats purity. Be lenient in what you accept. The zipfi

[issue14315] zipfile.ZipFile() unable to open zip File

Roundup Robot added the comment: New changeset 6dd5e9556a60 by Gregory P. Smith in branch '2.7': Fix issue #14315: The zipfile module now ignores extra fields in the central http://hg.python.org/cpython/rev/6dd5e9556a60 New changeset 33843896ce4e by Gregory P. Smith in branch '3.4': Fix issue #1

[issue14315] zipfile.ZipFile() unable to open zip File

Void added the comment: > FWIW, I think it will OK to just ignore extra fields that we can't > interpret as according to the standard. The only one we currently > care about is the "Zip64 extended information extra field". Also, > other programs (including the Info-Zip tools) seem to mostly ig

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: > I still don't see the bug; the module is behaving correctly - it is the > zipfile that is buggy. Supporting this specific kind of buggy zipfiles is a > new feature. I agree. The module is behaving correctly. -- __

[issue14315] zipfile.ZipFile() unable to open zip File

Terry J. Reedy added the comment: Given that the overall trend in the stdlib seems to be to be more lenient in parsing, as with htmlparser, and that the not-really-strict 'strict' parameter for that is being removed, (#15114) I do not understand the objection to accepting one more malformatio

[issue14315] zipfile.ZipFile() unable to open zip File

Martin v. Löwis added the comment: I still don't see the bug; the module is behaving correctly - it is the zipfile that is buggy. Supporting this specific kind of buggy zipfiles is a new feature. For reasons discussed, I also disagree with the proposed patch (file24902). If this helps to adva

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: I think this is a bugfix. I also don't think that "strict" attribute makes sense if we can't guarantee strong validity (see issue15114). -- ___ Python tracker __

[issue14315] zipfile.ZipFile() unable to open zip File

Terry J. Reedy added the comment: This issue is currently marked as a bugfix for current releases also. Since the proposal seems to be to introduce a new flag, should it be re-classified as enhancement (for 3.4)? -- ___ Python tracker

[issue14315] zipfile.ZipFile() unable to open zip File

Martin v. Löwis added the comment: Strictly speaking, the feature freeze has passed already, so you'll need the time machine. However, this is not the *final* feature freeze - there will be a 3.4 release of Python also. -- ___ Python tracker

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: Any chance to commit the patch before final feature freeze? -- ___ Python tracker ___ ___ Python-

[issue14315] zipfile.ZipFile() unable to open zip File

Meador Inge added the comment: > I would still like to see the zipfile module to be able to detect > ill-formed zipfiles - certainly not by default. Agreed. We already do produce some informational messages via the documented 'ZipFile.debug' attribute. Just checking that flag and producing

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: > That can't possibly be the reason. mmap requires 4k (4096) alignment (on > x86; more than that on SPARC). This may be the reason to mmap the entire file and then read aligned binary data. -- ___ Python tracker

[issue14315] zipfile.ZipFile() unable to open zip File

Martin v. Löwis added the comment: > Like I said before, I am all for dropping extra fields we can not > interpret. However, > let us be clear that with respect to the standard we are implementing > that zip files > constructed like this are ill-formed. I would still like to see the zipfile mo

[issue14315] zipfile.ZipFile() unable to open zip File

Martin v. Löwis added the comment: > This is definitely a padding issue. All uncompressed files are located > so that the data starts with a 4-byte boundary (1190+30+15+1=1236, 27486 > +30+17+3=27536, etc). This is, probably, allows the use of mmap for the > resources. That can't possibly be th

[issue14315] zipfile.ZipFile() unable to open zip File

Meador Inge added the comment: On Mon, May 14, 2012 at 12:31 PM, Serhiy Storchaka wrote: > Serhiy Storchaka added the comment: > >> This is definitely *not* a padding issue. > > This is definitely a padding issue. All uncompressed files are located > so that the data starts with a 4-byte boun

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: > This is definitely *not* a padding issue. This is definitely a padding issue. All uncompressed files are located so that the data starts with a 4-byte boundary (1190+30+15+1=1236, 27486 +30+17+3=27536, etc). This is, probably, allows the use of mmap for the

[issue14315] zipfile.ZipFile() unable to open zip File

Meador Inge added the comment: FWIW, I think it will OK to just ignore extra fields that we can't interpret as according to the standard. The only one we currently care about is the "Zip64 extended information extra field". Also, other programs (including the Info-Zip tools) seem to mostly ig

[issue14315] zipfile.ZipFile() unable to open zip File

Meador Inge added the comment: This is definitely *not* a padding issue. The problem is that one of the records has an extra field of length 1: $ zipinfo -v bla.apk ... Central directory entry #3: --- There are an extra 16 bytes preceding this file. res/raw/ice.p

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: > Just add a "strict" flag, make > it false by default, and raise an error if there is any unparsable > extra data. If the module does not actually checks the correctness of all (including local file headers, which now it ignores), it will be a false promise.

[issue14315] zipfile.ZipFile() unable to open zip File

Martin v. Löwis added the comment: >> So as a way out, I propose that the ZipFile class gains a "strict" >> attribute, indicating whether "acceptable" violations of the spec >> are ignored or reported as exceptions. > > It is a not easy task (and unnecessary, I suppose). Now zipfile > ignores ma

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: > I can sympathize with the desire to accept the zipfile, anyway (i.e. despite > it being broken). At the same time, I also think that Python should not let > errors pass silently. I do not know other implementation of ZIP, which output an error or a warnin

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: > Serhiy: can you please provide a unit test? The OP's test case is unsuitable > because of both size and copyright. I provided the test several minutes ago. -- ___ Python tracker

[issue14315] zipfile.ZipFile() unable to open zip File

Martin v. Löwis added the comment: Serhiy: can you please provide a unit test? The OP's test case is unsuitable because of both size and copyright. As for the actual issue: the extra data (type 0xcafe) is apparently added by jar tools to make the jar file executable: http://www.androidadb.co

[issue14315] zipfile.ZipFile() unable to open zip File

Changes by Serhiy Storchaka : Added file: http://bugs.python.org/file25564/zipfile_extra_test.patch ___ Python tracker ___ ___ Python-bugs-lis

[issue14315] zipfile.ZipFile() unable to open zip File

Changes by Éric Araujo : -- stage: -> test needed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue14315] zipfile.ZipFile() unable to open zip File

Yuval Greenfield added the comment: If we're modifying zipfile, please consider adding the reviewed patch for ZipFile.remove at http://bugs.python.org/issue6818 -- nosy: +ubershmekel ___ Python tracker __

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: Anyone can look at the patch? This same problem reported in http://bugs.python.org/msg73317 . -- ___ Python tracker ___

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: This is padding. Other implimentations just ignore it and Python must. -- keywords: +patch Added file: http://bugs.python.org/file24902/fix_zipfile_extra.patch ___ Python tracker

[issue14315] zipfile.ZipFile() unable to open zip File

Terry J. Reedy added the comment: Thanks. There must be multiple extra fields allowed. This output suggests that a) zipfile mis-parses the extra field in some peculiar case (which I doubt) or b) the file either gives a bad field length or third extra field is mal-formed and that other tools c

[issue14315] zipfile.ZipFile() unable to open zip File

Serhiy Storchaka added the comment: This is print from *other* _decodeExtra call. Add print('start') at start of _decodeExtra and you will see it. start b'\xfe\xca\x00\x00' 51966 0 b'' start start b'\x00' -- nosy: +storchaka ___ Python tracker

[issue14315] zipfile.ZipFile() unable to open zip File

Changes by Éric Araujo : -- nosy: +eric.araujo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue14315] zipfile.ZipFile() unable to open zip File

Terry J. Reedy added the comment: .apk is primarily used for Android Package files https://en.wikipedia.org/wiki/APK_%28file_format%29 which are zipped JAR-based archives. By changing .apk to .zip, I can open the file in Win7 explorer, which has zip built in. A 'crash' is a segfault or equvale

[issue14315] zipfile.ZipFile() unable to open zip File

New submission from pleed : zipfile.ZipFile("bla.apk") crashes, but should not since other tools work perfectly with this file. Python 2.7.2+ (default, Oct 4 2011, 20:06:09) [GCC 4.6.1] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import zipfile >>> zip