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