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.

Author void.sender
Recipients alanmcintyre, eric.araujo, loewis, mark.dickinson, meador.inge, pleed, serhiy.storchaka, terry.reedy, ubershmekel, void.sender
Date 2013-04-17.16:14:53
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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 ignore
> these fields.

Yes, please.

> The ellipsis is just a standard convention for indicating a repeating
> pattern.  Extra fields which are not multiples of four bytes are not
> properly formed.

. . .


Totally agree.  But at the very least it should check the size and raise a proper exception (e.g. BadZipFile).

FWIW, the code is already avoiding proper bounds checking using the built-in behavior of slicing -- 

    tp, ln = unpack('<HH', extra[:4])
    extra = extra[ln+4:]

-- which would otherwise throw exceptions if slice didn't innately and silently fail (due to an index being out-of-bounds).

> 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.

You realize that you are calling user-controlled data buggy, right?
Date User Action Args
2013-04-17 16:14:53void.sendersetrecipients: + void.sender, loewis, terry.reedy, mark.dickinson, alanmcintyre, eric.araujo, ubershmekel, meador.inge, serhiy.storchaka, pleed
2013-04-17 16:14:53void.sendersetmessageid: <>
2013-04-17 16:14:53void.senderlinkissue14315 messages
2013-04-17 16:14:53void.sendercreate