Minor Description
ZipArchiveInputStream.closeEntry() will not properly advance to the next entry causing the next call to getNextZipEntry to incorrectly return null if there are junk bytes at the end of the compressed data section.
More specifically, I found a case where the first entry's local header says that its compressed data size is 620 bytes. There are in fact 620 bytes before the next local header. However, when the compressed data is inflated, it only requires 618 of the 620 bytes to fully inflate (i.e. before it encounters the DEFLATE end of data code). This means that there is complete DEFLATE compressed data + extra garbage bytes after it, all within the specified zip entry data section.
The commons compress ZipArchiveInputStream streaming implementation doesn't exactly read on zip entry boundaries, but instead it reads 512 bytes at a time. As a result it tends to read more bytes than necessary per entry and then seek back to the beginning of the next entry. When it seeks back, it assumes that number of bytes that were required to be read to reach the end of the zip entry is the same as the number of bytes needed to inflate the data. However that assumption does not hold up in this case. 620 bytes need to be read to reach then end of the zip entry, but only 618 were needed to inflate the data. After the pushback, the closeEntry() method should perform a final drain of the remaining bytes to reach the next local file header.
I've created a test case and fix. I will submit a pull request shortly.