fix(deps): update dependency org.zeroturnaround:zt-zip from v1.17 to v1.18.2

[renovate]

This PR contains the following updates:

Package	Change	Age	Confidence
org.zeroturnaround:zt-zip	1.17 → 1.18.2

---

Release Notes

zeroturnaround/zt-zip (org.zeroturnaround:zt-zip)

v1.18.2

Compare Source

Security

• Windows only (no effect on other platforms): hardened the directory-traversal and output-directory checks used when unpacking against Windows path normalization. Windows strips a path component's trailing dots and spaces and treats : as a drive/stream separator, so an entry name like " ." could resolve to the output directory itself (re-applying the entry's permissions to it, GHSA-v2g6-7r9j-v6px) and a name like ".. \evil.txt" could escape the output directory. The allocation-free fast path that clears genuine descendant entry names (avoiding a getCanonicalFile() call) no longer clears such names; they are canonicalized and rejected as malicious when their canonical path cannot be resolved or does not stay inside the output directory. The output-directory check compares canonical java.nio.file.Paths so a self-referencing name is recognised even when getCanonicalFile() renders it with a trailing separator. Reported by Marcono1234.

v1.18.1

Compare Source

Fixed

• ZipUtil.unpack no longer applies a ZIP entry's stored file permissions to the output directory itself when an entry's name resolves to it (for example an entry named /), which could change the output directory's permissions (GHSA-v2g6-7r9j-v6px).

v1.18.0

Added

• pack overloads that write to an existing java.util.zip.ZipOutputStream.

Changed

• Raised the minimum runtime to Java 8 (bytecode target moved from 1.6 to 1.8).
• Upgraded the slf4j-api dependency from 1.6.6 to 2.0.18. zt-zip uses only the SLF4J API; applications that pick this newer API up transitively and still use an SLF4J 1.x binding must move to an SLF4J 2.x-compatible binding.
• slf4j-api is now a runtime-scoped dependency (previously compile scope), so it is no longer on the consumer compile classpath. Declare a direct slf4j-api dependency if your own code references SLF4J.

Fixed

• Zips unpack with a transformer no longer hangs when the transformer produces no entry, and a transformer that throws now surfaces its real exception to the caller instead of a misleading "Write end dead" pipe error.
• Zips.addEntry/addEntries no longer fail with "Stream closed" when adding a directory FileSource; a directory is now stored as a proper directory entry (#​138).
• ZipUtil.pack no longer fails with FileNotFoundException when a directory contains a broken (dangling) symbolic link; such entries are skipped (#​122).
• ZipUtil.packEntries/packEntry(File, File, NameMapper) now skip an entry whose NameMapper returns null (the same convention as the directory pack) instead of throwing NullPointerException and leaving a partial zip.
• The ZipUtil methods that take a separate destination — addEntry/addEntries, removeEntry/removeEntries, replaceEntry/replaceEntries, addOrReplaceEntries, transformEntry/transformEntries, repack — now reject a destination equal to the source with an IllegalArgumentException instead of truncating and destroying the source before reading it; use the in-place variant (without a destination) instead.
• ByteSource (and the byte[] ZipUtil.addEntry/replaceEntry overloads) now accept null bytes as the documented directory entry instead of throwing NullPointerException.
• ByteSource with null bytes and the STORED method now produces a valid empty entry (size 0, CRC 0) instead of failing with "STORED entry missing size, compressed size, or crc-32".

Security

• Hardened the relative path-traversal checks when unpacking, using java.nio.file.Path for consistent sub-directory containment checks.
• The Zips fluent API unpack path (Zips.get(...).unpack().destination(...).process()) now applies the same path-traversal guard as ZipUtil.unpack, rejecting entries that resolve outside the destination directory; this covers both the plain and transformer branches (#​180).
• In-place unpack now creates its temporary directory securely with Files.createTempDirectory (atomic, owner-only permissions) instead of a predictable, world-readable directory.
• AsiExtraField now validates the declared symbolic-link length against the bytes actually present before allocating, so a forged length in a crafted archive can no longer trigger a large (up to ~2 GB) memory allocation per entry while unpacking (#​181).
• AsiExtraField now rejects a truncated ASI extra field with a ZipException instead of letting an ArrayIndexOutOfBoundsException/NegativeArraySizeException abort unpacking, completing the bounds check added in #​181.
• BackslashUnpacker now validates the resolved path before creating any directories, so a backslash-separated ..\ entry can no longer create directories outside the output directory (the file write itself was already blocked).
• ZipUtil.explode, repack and unexplode now create their working file or directory atomically (File.createTempFile / Files.createTempDirectory) instead of a predictable name next to the target, closing a symlink/TOCTOU race when the target sits in a shared directory; the predictable FileUtils.getTempFileFor helper is deprecated.
• ZipUtil.unwrap now throws a ZipException for an entry name whose path prefix resolves outside the name (such as a ~- or :-prefixed name) instead of letting an unchecked StringIndexOutOfBoundsException abort the operation.

---

Configuration

📅 Schedule: (UTC)

• Branch creation
  • At any time (no schedule defined)
• Automerge
  • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR was generated by Mend Renovate. View the repository job log.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud