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 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.
. . .
[;pause;]
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?
----------
nosy: +void.sender
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue14315>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
