On Mon, 16 Feb 2026 11:08:46 GMT, Eirik Bjørsnøs <[email protected]> wrote:
> Please review this test-only PR which introduces a test for an edge case in > `ZipFile.Source.findEND`. > > ZIP files may some times have bytes padded to them after the fixed-size END > header. This may be bytes of the comment or just unrelated bytes. Because of > this ,`ZipFile.Source.findEnd()` parses the ZIP file in a "backwards" manner, > looking for ENDSIG sequences indicating that a candidate END header is found. > > If the position of the candidate END header and its declared comment length > do not match up with the actual ZIP file length, this indicates padded bytes. > In this case, `findEND()` will sanity check that the candidate END header > points to LOCOFF and CENOFF positions which actually have the expected > LOCSIG and CENSIG bytes. > > The case where a candidate END header is valid but has 'unexpected' bytes > padded after it is currently tested by `ReadZip::bytesPaddedAtEnd`. However, > there is no current testing for the case where an unrelated `ENDSIG` byte > sequence is present in the padded bytes and the sanity check of the LOCOFF > and CENOFF contents fails. > > This is edge case is propably rare in the real world, but it would still be > nice to have an automated test of this scenario. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/29740
