chore: bump jackson to 2.18.10 and logback to 1.3.16 - #22
Conversation
Clears the outstanding advisories against the SDK's directly declared
dependencies:
jackson-core / jackson-databind / jackson-datatype-jsr310
2.17.1 -> 2.18.10
logback-core / logback-classic
1.3.14 -> 1.3.16
A consumer-facing scan goes from 3 HIGH, 7 MEDIUM and 4 LOW findings
down to 3 LOW. The three that remain are logback-core issues whose fixes
exist only in the 1.5.x line, which requires Java 21. 1.3.16 is the last
release of the Java 8 compatible line.
All upgraded artifacts are still Java 8 bytecode and the public API is
unchanged: 608 public signatures identical to the published 3.0.8 jar
built from this same source. Verified with the existing 33 tests plus a
28 assertion end-to-end run against a live instance on JDK 8 and JDK 11.
|
💬 Discussion in Slack: #pr-review-java-sdk-22-chore-bump-jackson-to-2-18-10-and-logback-to-1-3-16 Posted by Review Police — reviews, comments, new commits, and CI failures will stream into this channel. |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
|
| Filename | Overview |
|---|---|
| pom.xml | Updates Jackson and Logback versions; Jackson appears compatible, while the selected Logback version remains advisory-affected despite being an unused compile-scoped dependency. |
Reviews (1): Last reviewed commit: "chore: bump jackson to 2.18.10 and logba..." | Re-trigger Greptile
| <groupId>ch.qos.logback</groupId> | ||
| <artifactId>logback-core</artifactId> | ||
| <version>1.3.14</version> | ||
| <version>1.3.16</version> |
There was a problem hiding this comment.
This upgrade does not clear the Logback advisories described by the PR: logback-core and logback-classic 1.3.16 remain affected by the three identified 2026 advisories. Both dependencies are compile-scoped even though production code does not use Logback, so SDK consumers still receive the affected artifacts transitively and dependency scans will continue to report them. Consider removing the unused logging dependencies or choosing a compatible remediation strategy.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
|
For the socket check: Pulled logback-core 1.3.16 and inspected the two flagged classes directly. PropertyModel is an ordinary Java bean: four private fields with getters and setters, standard equals and hashCode, and a mirror method for copying state. ShutdownHookModelHandler reads a class name from the parsed logging config, falls back to a default, and registers the result as a JVM shutdown hook. Neither shows any sign of obfuscation. All string constants are readable English log messages, debug information and source file names are intact, method and field names are fully descriptive, and the jar contains no mangled or single-letter class names anywhere. The artifact matches its Maven Central checksum, is GPG signed, and is published by QOS.ch. |
Clears the outstanding advisories against the SDK's directly declared dependencies:
jackson-core / jackson-databind / jackson-datatype-jsr310
2.17.1 -> 2.18.10
logback-core / logback-classic
1.3.14 -> 1.3.16
All upgraded artifacts are still Java 8 bytecode and the public API is unchanged: 608 public signatures identical to the published 3.0.8 jar built from this same source. Verified with the existing 33 tests plus a 28 assertion end-to-end run against a live instance on JDK 8 and JDK 11.