spuru9 opened a new pull request, #1170:
URL: https://github.com/apache/flink-kubernetes-operator/pull/1170

   ## What is the purpose of the change
   
   Clears the Logback CVEs tracked in 
[FLINK-40246](https://issues.apache.org/jira/browse/FLINK-40246) by moving the 
logging stack to SLF4J 2.x, which is a prerequisite for any patched Logback 
release.
   
   `logback-core` 1.2.13 is the terminal release of an EOL line, so the CVEs 
filed against it have no fix on that branch. Every patched Logback release 
(1.3.15+/1.5.13+) targets SLF4J 2.x, while the operator pins `slf4j-api` 
1.7.36. The two cannot move independently: Logback 1.2.13 binds only to SLF4J 
1.7.x, Logback 1.5.x binds only to SLF4J 2.x, and bumping either alone leaves 
SLF4J unbound so all log output is silently discarded.
   
   The SLF4J pin is also incorrect on its own terms, independently of the CVEs. 
JOSDK 5.5.0 and fabric8 7.8.0 both declare `slf4j-api` 2.0.18, but the 
operator's direct 1.7.36 declaration wins over their transitive one. 
`ReconciliationDispatcher.handleErrorStatusHandler` calls 
`Logger.atLevel(Level)`, which does not exist in 1.7.36:
   
   ```
   java.lang.NoSuchMethodError: 'org.slf4j.spi.LoggingEventBuilder
       org.slf4j.Logger.atLevel(org.slf4j.event.Level)'
     at 
ReconciliationDispatcher.handleErrorStatusHandler(ReconciliationDispatcher.java:247)
     at 
ReconciliationDispatcher.handleReconcile(ReconciliationDispatcher.java:147)
     at 
ReconciliationDispatcher.handleDispatch(ReconciliationDispatcher.java:111)
     at 
ReconciliationDispatcher.handleExecution(ReconciliationDispatcher.java:76)
   ```
   
   This is reachable when a `FlinkStateSnapshot` reconcile fails and the 
subsequent error-status patch also fails (409 conflict, 422, RBAC denial, 
timeout). It is an `Error`, and `handleExecution` catches only `Exception`, so 
it escapes the dispatcher and takes the original reconcile failure with it. The 
call site entered with JOSDK 5.2.2 (FLINK-38875), so 1.14.x and 1.15.x are 
affected as well; JOSDK 5.1.2 is clean.
   
   ## Brief change log
   
     - `slf4j-api` 1.7.36 -> 2.0.18, matching what JOSDK and fabric8 already 
declare
     - `logback-classic` / `logback-core` 1.2.13 -> 1.5.34
     - `log4j-slf4j-impl` -> `log4j-slf4j2-impl` across all modules, including 
the `maven-dependency-plugin` artifact item that stages the binding into the 
Docker image
     - `logback-core` declared as a `provided` dependency rather than existing 
only as a dependency-plugin artifact item
     - Removed `log4j-slf4j-impl` from the operator `NOTICE`: it became 
`provided` in FLINK-39501 and has not been bundled since. Refreshed the 
`slf4j-api` versions in both `NOTICE` files
     - Rewrote the "Logging Library Version Overrides" hint in 
`docs/content{,.zh}/docs/operations/logging.md`. It documented the old 
constraint with the wrong failure mode, claiming `ClassNotFoundException: 
org.slf4j.impl.StaticLoggerBinder`; SLF4J actually falls back to a NOP logger 
and discards output without raising anything
   
   Note that 1.5.34 rather than 1.5.25 is required. Beyond the three CVEs 
listed in the JIRA, `logback-core` 1.2.13 is also flagged for CVE-2024-12801 
(GHSA-6v67-2wr5-gvf4, fixed 1.3.15/1.5.13), CVE-2026-9828 (GHSA-p47f-322f-whfh, 
fixed 1.5.33) and CVE-2026-10532 (GHSA-jhq6-gfmj-v8fx, fixed 1.5.34).
   
   ## Verifying this change
   
   This change is already covered by existing tests. The full suite passes 
locally: 2216 tests in `flink-kubernetes-operator`, 105 in 
`flink-kubernetes-webhook`, plus `flink-kubernetes-standalone`, 
`flink-kubernetes-operator-api`, `flink-autoscaler`, 
`flink-autoscaler-standalone`, `flink-autoscaler-plugin-jdbc` and 
`flink-kubernetes-docs`.
   
   `e2e-tests/test_logback_logging.sh` is the meaningful gate here, since it 
asserts no duplicate-binding warning across Flink 1.20/2.0/2.1/2.2 for both 
native and standalone modes. That runs in the `e2e_logging` CI job. Opening as 
a draft until it has run against a real cluster.
   
   Both framework paths were also checked manually against the built image 
layout:
   
   ```
   log4j2:  Repro [WARN ] ErrorStatusUpdateControl.patchStatus failed for 
test-resource
   logback: [main] WARN Repro -- ErrorStatusUpdateControl.patchStatus failed 
for test-resource
   ```
   
   I have a regression test that drives the real `ReconciliationDispatcher` 
down the error path above; it fails with the `NoSuchMethodError` on 1.7.36 and 
passes on 2.0.18. It is not included here since it has to live in the 
`io.javaoperatorsdk.operator.processing.event` package to reach the 
package-private dispatcher. Happy to add it if reviewers would like it.
   
   ## Does this pull request potentially affect one of the following parts:
   
     - Dependencies (does it add or upgrade a dependency): **yes** - 
`slf4j-api`, `logback-classic`, `logback-core`, and `log4j-slf4j-impl` is 
replaced by `log4j-slf4j2-impl`
     - The public API, i.e., is any changes to the `CustomResourceDescriptors`: 
no
     - Core observer or reconciler logic that is regularly executed: no
   
   ## Documentation
   
     - Does this pull request introduce a new feature? no
     - If yes, how is the feature documented? not applicable - existing logging 
documentation updated
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to