Hello,
We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
entries are intact) that causes a runtime exception when scanning its
contents with ZipFileSystem. The exception indicates an invalid
signature when parsing EXTID_EXTT. I don't quite understand this
comment in the code:
case EXTID_EXTT:
// spec says the Extened timestamp in cen only has mtime
// need to read the loc to get the extra a/ctime, if flag
// "zipinfo-time" is not specified to false;
// there is performance cost (move up to loc and read) to
// access the loc table foreach entry;
if (zipfs.noExtt) {
if (sz == 5)
mtime = unixToJavaTime(LG(extra, pos + 1));
break;
}
...
but this ZIP file has the extra data block of exactly 5 bytes, as
indicated by zipinfo:
Central directory entry #6:
---------------------------
...
file system or operating system of origin: Unix
version of encoding software: 3.0
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
...
extended local header: no
file last modified on (DOS date/time): 2018 Mar 1 04:56:20
file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
...
Unix file attributes (100000 octal): ----------
MS-DOS file attributes (01 hex): read-only
The central-directory extra field contains:
- A subfield with ID 0x5455 (universal time) and 5 data bytes.
The local extra field has UTC/GMT modification/access times.
The above conditional block checking for length == 5 would have worked
in ZipFileSystem but it's surrounded by a condition over an
externally-provided property - zipfs.noExtt is only set to true if:
this.noExtt = "false".equals(env.get("zipinfo-time"));
I can't share this particular ZIP file with you and I don't know how
it was created but it seems like that "zipinfo-time" flag could be
omitted if the length of the extra data field is exactly 5?
Dawid
