chore(deps): Bump io.github.classgraph:classgraph from 4.8.184 to 4.8.192

[dependabot]

Bumps io.github.classgraph:classgraph from 4.8.184 to 4.8.192.

Release notes

Sourced from io.github.classgraph:classgraph's releases.

ClassGraph 4.8.192

ClassGraph 5.0.0 is coming shortly, and requires JDK 17 or newer. 4.8.192 is a bugfix release on the 4.x maintenance branch, and continues the file-by-file audit of the codebase that produced 4.8.190 and 4.8.191. As before, the bugs listed here were found by Claude through careful code analysis, and were fixed on the v5 branch and backported to v4.

Bug fixes: zipfile reading

• A zip entry name was decoded as UTF-8 whether or not the entry said it was UTF-8. The zip specification says a name is encoded in IBM Code Page 437 unless bit 11 of the entry's general purpose bit flag is set, and Windows Explorer and Info-ZIP are among the tools that follow it. So the name of an entry written by one of those tools came out as garbage as soon as it contained a byte outside ASCII, and the class or resource could not be found under the name it was stored with. The flag is now read before the name, and the name decoded as CP437 or UTF-8 accordingly. Malformed UTF-8 no longer throws either: an undecodable byte is replaced rather than the whole entry being lost, which is what java.util.zip does.

Bug fixes: resources

• Resource#read() returned a buffer covering the entire jarfile rather than the entry, when memory mapping was in use. The buffer's position was the entry's offset, so a sequential read returned the right bytes, but capacity() was the size of the whole jarfile, an absolute read such as get(0) read from the start of the jarfile, and clear() widened the buffer back out over the zip headers and every other entry. The mapping is now narrowed to the entry, so the buffer starts at position zero and cannot be widened again.

• A module resource's content was aliased rather than copied. The buffer belongs to the ModuleReader, which reclaims it when the resource is closed, so the content could change underneath a caller that kept the buffer.

Bug fixes: classpath order

• A classpath element named from more than one place got a single position, when it does not have one. The index of a classpath element within the Class-Path manifest entry (or lib directory) of the element that named it was stored on the child element rather than on the edge from the parent, and merged to the smallest index across every reference to that child. The same jarfile can be named by the Class-Path entries of two different jarfiles at a different position within each of them, so there is no one position it occupies.

  Two consequences, both of which decide which of two copies of a class masks the other: an element that was also listed on the top-level classpath sorted ahead of all of its parent's other entries, and an element named by two parents took the lower of its two indices under both, so it could tie with a sibling and fall back on whichever order the parallel scan tasks happened to finish in. Fixes #810.

ClassGraph 4.8.191

ClassGraph 5.0.0 is coming shortly, and requires JDK 17 or newer. 4.8.191 is a bugfix release on the 4.x maintenance branch, and continues the file-by-file audit of the codebase that produced 4.8.190. As before, the bugs listed here were found by Claude through careful code analysis, and were fixed on the v5 branch and backported to v4.

Spring Boot 3.2 and later

• A Spring Boot 3.2+ or 4.x executable jar is now scanned. Since 3.2, the Spring Boot launcher addresses an entry inside an executable jar or war using its own nested: URL protocol, which separates the path of the outer archive from the name of the entry within it with /! rather than the standard !/ — for example jar:nested:/path/to/app.jar/!BOOT-INF/lib/dependency.jar!/. Those are the URLs its classloader hands out, so ClassGraph resolved every one of them as a relative file path and found nothing at all: a scan of a Spring Boot 3.2+ executable jar returned zero classes. Such URLs are now converted to the equivalent jar: URL, and a classpath string containing one is no longer split at the nested: scheme's colon.

Behavior changes

• The classpath order no longer depends on the order a filesystem happens to return directory entries in. The jars of an automatic lib directory of a directory classpath element (lib/, BOOT-INF/lib/, WEB-INF/lib/ and the rest) and the JRE's own lib and ext jars are now sorted by filename, so the same JRE and the same application produce the same classpath order on every machine, and which of two jars containing the same class masks the other no longer varies from run to run. Each lib directory is sorted on its own, so the order of the lib directory prefixes still decides which one's jars come first. A dir/* wildcard classpath entry is deliberately left unsorted, because that reproduces the java launcher's own expansion order.

• ScanResult#getPackageInfo() and #getModuleInfo() return sorted lists. They previously returned hashmap iteration order, which varies between runs.

Bug fixes: zipfile reading

• Every zipfile larger than 4 GB was misread. The Zip64 extended information extra field was read as though all of its values are always present, when in fact it carries only the values that overflowed their 32-bit fields, in a fixed order. The fields present are now determined by which of the 32-bit values are set to the overflow marker.

• A zipfile whose comment is longer than 65514 bytes could not be opened. The search for the end-of-central-directory record stopped short of the largest comment the format permits.

• A zip entry whose compressed size runs past the end of the archive threw IllegalArgumentException out of the zipfile reader, rather than being reported as the malformed archive it is. An entry whose Zip64 compressed size overflowed a 64-bit addition was silently read past its end. Both now throw IOException.

• A central directory record declaring an extra field area that extends past the end of the central directory made the whole zipfile unopenable. An empty Info-ZIP Unicode path extra field also made ClassGraph read one byte outside the field. Records are now read strictly within their own bounds.

• A zip entry's Unix timestamp extra field was read as an 8-byte time rather than the 4-byte time the format specifies, so entries written by zip(1), Info-ZIP or Gradle silently fell back to their coarse local-time MS-DOS timestamps.

• A stream that returned zero from two consecutive reads made ClassGraph read a jarfile as empty. A zero-length read is not end of stream.

• A classfile attribute close to 2 GB wrapped the read position negative in ClassfileReader.skip(int).

• The log message "Skipping zip entry with invalid extra field size" claimed an entry was skipped when it was still read.

... (truncated)

Commits

• 1014e87 [maven-release-plugin] prepare release classgraph-4.8.192
• a10fafe Order child classpath elements by their position within each parent
• b804842 Return a buffer that covers only the requested resource
• c7d5192 Decode zip entry names as CP437 unless the entry says they are UTF-8
• 71fe4d9 [maven-release-plugin] prepare for next development iteration
• ac292fd [maven-release-plugin] prepare release classgraph-4.8.191
• 7493141 Fix a JRE lib jar sorting test that assumed a canonical temp directory
• 4a56491 Scan Spring Boot executable jars addressed by "nested:" URLs
• db01c87 Sort directory listings that feed the classpath into a fixed order
• 7d8eb6d Decode characters outside the Basic Multilingual Plane in a URL path
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)