[COMPRESS-482] ZipArchiveInputStream's "data descriptor for stored entries" feature doesn't work if the data descriptor doesn't contain a signature

• Type: Bug
• Status: Resolved
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.18
• Fix Version/s: 1.19
• Component/s: Archivers
• Labels: zip
• Assignee: Unassigned
• Reporter: Stefan Bodewig
• Created: 18/Apr/19 18:57
• Updated: 18/Aug/19 19:59
• Resolved: 18/Aug/19 10:12

Description

In the first branch of the next block from bufferContainSignature

                if ((buf.array()[i + 2] == LFH[2] && buf.array()[i + 3] == LFH[3])
                    || (buf.array()[i] == CFH[2] && buf.array()[i + 3] == CFH[3])) {
                    // found a LFH or CFH:
                    readTooMuch = offset + lastRead - i - expectedDDLen;
                    done = true;
                }
                else if (buf.array()[i + 2] == DD[2] && buf.array()[i + 3] == DD[3]) {
                    // found DD:
                    readTooMuch = offset + lastRead - i;
                    done = true;
                }

readTooMuch should probably add expectedDDLen rather than subtract it. It leaves the DD inside of the read stream for the last stored entry rather than positioning the stream in front of it. Unfortunately we don't seem to have a single unit test that would execute the branch.

Also the current implementation of bufferContainSignature will stop when a local file header is found even before enough data for a data descriptor has been read at all. In COMPRESS-480 it will detect the very first local file header in the embedded XPI file at offset 0 even though there must be twelve bytes of data descriptor before the first candidate.