Message187177
| 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 |
<1366215293.7.0.935721072236.issue14315@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
> 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? |
|