"loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data field of exactly 5 bytes)

[Dawid Weiss]

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