From b229f5264421525ac6d7f0216b1e198b2b948e44 Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 19:17:38 +0000 Subject: [PATCH 1/2] docs(build): the log4j pin is a floor guard now, not an active CVE fix Both comments still said logcaptor "brings 2.25.3, which is affected by CVE-2026-49844". That stopped being true when this repo moved to logcaptor 2.12.7: its own pom declares 2.26.1, i.e. exactly what the pin forces. The dependencyManagement entries therefore change nothing about the resolved graph today. The pin is kept deliberately, as a lower bound, so a logcaptor release that fell back to an affected line could not regress the test classpath silently. But a comment that describes it as the fix sends the next reader looking for a vulnerability that is no longer reachable. Also states what the pin is NOT, because the two changes are adjacent in time and easy to conflate: this has nothing to do with the Java 8 class-file floor. That one is slf4j-simple instead of logback and checker-qual at provided scope, and it concerns the shipped artifact. Both log4j artifacts are test scope and reach no published artifact at all. Comment text only; no version, scope or dependency changed. Kept byte-parallel with the same rewrite in BitcoinAddressFinder, which carries the identical pin. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH --- llama/pom.xml | 26 +++++++++++++++++--------- 1 file changed, 17 insertions(+), 9 deletions(-) diff --git a/llama/pom.xml b/llama/pom.xml index e62c620e..909cfa45 100644 --- a/llama/pom.xml +++ b/llama/pom.xml @@ -74,11 +74,18 @@ SPDX-License-Identifier: MIT 0.16 3.7 2.12.7 - + 2.26.1 1.2.28 + org.apache.logging.log4j log4j-api From 57b1e5b78cc6e15763bde8e0bfadd1c9c83177fc Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 5 Sep 2026 19:19:40 +0000 Subject: [PATCH 2/2] build(deps): upgrade langchain4j from 1.19.0 to 1.20.0 The only dependency in the four sibling repos genuinely behind a stable upstream. It is confined to this one module, so it reaches no other artifact: llama-langchain4j is maven.compiler.release 17 because langchain4j 1.x requires Java 17, while the core net.ladenthin:llama stays Java 8. That split is untouched. Nothing about the pin was deliberate -- no rationale comment accompanied it, and it is not in the workspace do-not-bump registry. It was simply a lag. Verified rather than assumed, because a langchain4j minor can move interface shapes and this module implements four of them. The module imports 44 types across agent.tool, data.message, model.chat.request(.json), model.chat.response and model.output; all still resolve, and the adapters compile unchanged against ChatModel, StreamingChatModel, EmbeddingModel and ScoringModel: mvn -pl llama -am -DskipTests install -> BUILD SUCCESS mvn -f llama-langchain4j/pom.xml verify -> BUILD SUCCESS Tests run: 49, Failures: 0, Errors: 0, Skipped: 7 The 7 skips are the model-gated integration tests, which self-skip without a GGUF; the 42 that ran are the mapping, schema-serializer and streaming-assembler suites, i.e. exactly the code that touches the langchain4j API surface. `verify` is the right goal here rather than `test`: it also builds the javadoc jar, so a javadoc break introduced by a changed signature fails now instead of at release time. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01AnNYn8W1xuVxVJtyL34GyH --- llama-langchain4j/pom.xml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/llama-langchain4j/pom.xml b/llama-langchain4j/pom.xml index 8a42093d..34d5582a 100644 --- a/llama-langchain4j/pom.xml +++ b/llama-langchain4j/pom.xml @@ -57,7 +57,7 @@ SPDX-License-Identifier: MIT UTF-8 17 - 1.19.0 + 1.20.0 6.1.3 3.0