spring-boot

Spring Boot

Andy Wilkinson 47163af9b6 Fix handling of Zip64 jar files larger than 4,294,967,295 bytes Previously, a Zip64 jar file was identified by the number of entries in the central directory being 0xFFFF. This value indicates that there the number of entries is too big for the 2-byte field. However, a jar may be in Zip64 format due to it exceeding the Zip format's maximum size rather than its maximum number of entries so this field cannot be used as a reliable indicator. The Zip specification doesn't require any of the fields of the end of central directory record to have a value of 0xFFFF (2-byte fields) or 0xFFFFFFFF (4-byte fields) when using Zip64 format so we need to take a different approach. Additionally, a number of places in the code assumed that an entry's offset would always be available from the central directory file header directly. This assumption did not hold true when the jar was a Zip64 archive due to its size as the offset's value would be 0xFFFFFFF indicating that it should be read from the Zip64 extended information field within the header's extra field instead. This commit updates the Zip64 detection to look for the Zip64 end of central directory locator instead. If present, it begins 20 bytes before the beginning of the end of central directory record. Its first four bytes are always 0x07064b50. The code that reads the local header offset has also been updated to refer to the Zip64 extended information field when the offset is too large to fit in the 4-byte field in the central directory file header. To allow greater-than-4-byte offsets to be handled, a number of fields, method parameters, and local variables have had their type changed from an int to a long. Fixes gh-27822	4 years ago
..
src	Fix handling of Zip64 jar files larger than 4,294,967,295 bytes	4 years ago
build.gradle	Add junit-platform-launcher dependency by convention	5 years ago

Andy Wilkinson 47163af9b6 Fix handling of Zip64 jar files larger than 4,294,967,295 bytes

Previously, a Zip64 jar file was identified by the number of entries
in the central directory being 0xFFFF. This value indicates that
there the number of entries is too big for the 2-byte field. However,
a jar may be in Zip64 format due to it exceeding the Zip format's
maximum size rather than its maximum number of entries so this field
cannot be used as a reliable indicator. The Zip specification doesn't
require any of the fields of the end of central directory record to
have a value of 0xFFFF (2-byte fields) or 0xFFFFFFFF (4-byte fields)
when using Zip64 format so we need to take a different approach.

Additionally, a number of places in the code assumed that an entry's
offset would always be available from the central directory file
header directly. This assumption did not hold true when the jar was
a Zip64 archive due to its size as the offset's value would be
0xFFFFFFF indicating that it should be read from the Zip64 extended
information field within the header's extra field instead.

This commit updates the Zip64 detection to look for the Zip64 end of
central directory locator instead. If present, it begins 20 bytes
before the beginning of the end of central directory record. Its
first four bytes are always 0x07064b50. The code that reads the
local header offset has also been updated to refer to the Zip64
extended information field when the offset is too large to fit in
the 4-byte field in the central directory file header. To allow
greater-than-4-byte offsets to be handled, a number of fields,
method parameters, and local variables have had their type changed
from an int to a long.

Fixes gh-27822

4 years ago

src

Fix handling of Zip64 jar files larger than 4,294,967,295 bytes

4 years ago

build.gradle

Add junit-platform-launcher dependency by convention

5 years ago