# Dependency review 1.4.0 — 2026-09-01

## Scope

- No library, plugin, Gradle, Kotlin, Compose, JDK or IDE dependency was changed.
- ZIP inspection and bounded extraction use `java.util.zip` and `java.nio.file` from the already
  packaged JDK runtime.
- The desktop UI adds only Swing components that are already part of the packaged `java.desktop`
  module.

## Decision

- Keep all dependency and toolchain versions from 1.3.1.
- Prefer the JDK ZIP reader over a new archive dependency to keep the attack surface and SBOM stable.
- Treat encrypted archives and nested archive recursion as unsupported; enforce entry, size, ratio,
  free-space, path and CRC checks before accepting extracted input.

## Stable-update review

Review date: 2026-09-01. The generated `dependency-updates.json` checked the project declarations
against the official repository metadata and linked upstream project pages. Gradle 9.7.1, Kotlin
2.4.10, Compose Multiplatform 1.12.0, Material 3 1.9.0, coroutines 1.11.0, Mapsforge 0.29.0,
Apache SIS 1.6, CycloneDX 3.4.1, OSV Scanner 2.5.1, Microsoft OpenJDK 25.0.4.1 and Android Studio
2026.1.3 Patch 1 remain the reviewed toolchain for this release; no direct project update is required
for the ZIP feature.

The report lists newer Guava, JAXB, SQLite JDBC and related support-library releases. Those version
entries describe the exact contents of the two verified official Mapsforge writer fat JARs for SBOM
purposes; they cannot be upgraded independently without replacing or rebuilding those writer
artifacts and revalidating Mapsforge output compatibility. The Kotlin build-tools 2.4.0 entry belongs
to an internal compatibility configuration, while the active compiler and plugins are already
2.4.10. These candidates are therefore retained for 1.4.0 rather than changing unrelated binary
components during an archive-security feature release.

## Security gate

The Windows and Linux CycloneDX SBOMs each contain 243 packages. OSV Scanner reports no known
vulnerabilities for either platform, and no vulnerability exception is active.

The compatibility risk is low because direct file import is unchanged and archive entries enter the
same existing inspection workflow after bounded extraction.
