Clear CVE Dependabot alerts: Curator/ZooKeeper bump, assertj, e2e test fixtures#13913
Merged
Conversation
…hon fixtures Shipped (oap-server-bom + LICENSE + docs): - Apache Curator 4.3.0 -> 5.9.0 (curator-test too) and ZooKeeper 3.5.7 -> 3.9.5, bumped together (Curator 5.x is the line carrying the ZK 3.9.x client). Clears CVE-2023-44981. OAP is a ZK client only so the server-side bug was never reachable, but the bundled jar tripped Dependabot. Plugins use only stable Curator APIs; no source changes. Supported ZooKeeper server version is now 3.5+ (3.4.x dropped by Curator 5.x). LICENSE + cluster docs + application.yml updated. Build/test scope: - assertj-core 3.20.2 -> 3.27.7 (CVE-2026-24400, test scope only). e2e test fixtures (test/e2e-v2, never shipped): - guava -> 32.0.0-jre, kafka-clients -> 3.9.2, log4j-core -> 2.25.4, logback -> 1.2.13 (Java-8 line), json-path -> 2.9.0, flask -> 3.1.3, protobuf -> 4.25.8. The 17 Go-fixture alerts require a go1.24 toolchain (grpc 1.79.3 / x-crypto 0.45 need go 1.24, above skywalking-go's published go1.23 ceiling) and are handled separately: skywalking-go go1.24 enablement + e2e go fixture migration.
…entifiable) The Dependency-licenses CI job failed because `license-eye dependency resolve` cannot auto-identify the license of the org.apache.zookeeper:zookeeper / zookeeper-jute 3.9.5 jars (reported as "Unknown" -> "failed to identify the licenses"), so the resolve step exited 1 before the LICENSE diff check. Add an explicit Apache-2.0 override in .licenserc.yaml for both artifacts, mirroring the existing overrides (okhttp, retrofit, postgresql, ...). Verified locally with the CI-pinned license-eye: resolve now succeeds and regenerates a LICENSE identical to the committed one (the LICENSE content was already correct).
… 3.6+
The Cluster ZK e2e tests failed (oap1 unhealthy): the OAP's new Curator 5.9.0 /
ZooKeeper 3.9.5 client cannot register its instance against the e2e's EOL
zookeeper:3.5 server. Reproduced locally: Curator 5.x ServiceDiscovery
(watchInstances=true) issues `addWatch` (persistent watch, opcode 106), which
ZooKeeper added in server 3.6.0; a 3.5 server rejects it ("Received packet at
server of unknown type 106") so the create request fails with ConnectionLoss ->
ModuleStartException -> oap1 unhealthy. Verified the same path succeeds on
zookeeper:3.6 and 3.9, fails on 3.5.
- e2e: bump zookeeper:3.5 -> zookeeper:3.9 (matches the bundled 3.9.x client) in
cases/cluster/zk/{es,banyandb}.
- Correct the documented minimum from 3.5+ to 3.6+ (application.yml,
backend-cluster.md, changes.md) -- persistent watches require server 3.6.0.
…r 3.6+)
Same root cause as the cluster e2e: the OAP's curator 5.9.0 client uses persistent
watches (addWatch, ZooKeeper 3.6.0+), which a zookeeper:3.5 server rejects
("unknown type 106") -> ConnectionLoss. This made the Integration test suite hang
(1h timeout, via the two zk testcontainer ITs) and the Virtual Gateway e2e fail
(oap1 unhealthy).
Bump the three remaining OAP-coordinator test servers zookeeper:3.5 -> 3.9:
- ClusterModuleZookeeperProviderFunctionalIT (cluster-zookeeper-plugin)
- ZookeeperConfigurationIT (configuration-zookeeper)
- e2e cases/gateway/docker-compose.yml
Validated locally on zk:3.9: both ITs pass (5 + 2 tests, no hang).
GitHub-hosted runners (ubuntu-24.04) ship only Docker Compose v2 and no longer provide the legacy docker-compose v1 binary, so the infra-e2e log collector failed on current runners. Bump the pinned infra-e2e action from 0d91769 to 68bbdec (apache/skywalking-infra-e2e#148), which switches the collector to 'docker compose', restoring e2e container-log collection.
…ilure
A docker-compose e2e case that hangs (e.g. the trigger never gets a 2xx)
runs until the job hits timeout-minutes, which marks the job 'cancelled' —
NOT 'failure'. The existing 'if: ${{ failure() }}' diagnostic and
upload-artifact steps are therefore skipped, so a timed-out case produces
ZERO logs, making it undebuggable. On top of that, infra-e2e's own log
collector never runs when the trigger hangs (cleanup is never reached), so
the collected dir would be empty even if uploaded.
Fix the two docker-compose e2e jobs to also run on 'cancelled()', and add a
'Dump container logs' step that writes 'docker logs' for every container
directly into SW_INFRA_E2E_LOG_DIR while the containers are still alive, so
a hung/cancelled case still uploads provider/nginx/oap/banyandb logs.
The istio/k8s jobs are left unchanged (they would need a kubectl-based dump).
wankai123
approved these changes
Jun 18, 2026
1 task
wu-sheng
added a commit
that referenced
this pull request
Jun 18, 2026
…e2e hang) #13913 bumped logback-classic to 1.2.13, but Spring Boot's dependency management held logback-core at 1.2.6. logback-classic 1.2.13's ThrowableProxy calls OptionHelper.isNotEmtpy(), which only exists in logback-core 1.2.13, so logging ANY exception threw NoSuchMethodError and killed the Tomcat request thread. The Agent Lua e2e trigger (POST /nginx/entry/info) hits an exception-logging path: its first request died with no response, so the e2e HTTP trigger blocked until the 60-min job timeout -- the long-mysterious 'environmental' lua hang. Other cases (and local runs) passed only because they never logged an exception. Pin logback-core to ${logback.version} (1.2.13). Verified: OptionHelper.isNotEmtpy is absent in logback-core 1.2.6, present in 1.2.13.
wu-sheng
added a commit
that referenced
this pull request
Jun 18, 2026
…Go fixtures (#13915) ### Clear test-scope CVE Dependabot alerts (log4j 1.x + Go e2e fixtures) Follow-up to #13913. Clears ~18 of the remaining open Dependabot alerts, all in e2e **test fixtures** (no production code). **log4j 1.x** — `e2e-service-provider` (2 alerts; log4j 1.x is EOL, one CVE has no patched release): - Removed `log4j:log4j` 1.2.17 + `apm-toolkit-log4j-1.x` and `log4j.properties`. The provider already exercises log-to-OAP through **log4j2** (`apm-toolkit-log4j-2.x`, grpc appender) and **logback** in parallel, so log-reporting coverage is preserved. The log4j2 loggers now use the imported `org.apache.logging.log4j.Logger` (no inline FQCN). Dropped the log4j-1.x `fileLogger` items from the filebeat/fluentd expected files. **Go fixtures** — `grpc`/`golang.org/x/net`/`x/crypto`/`protobuf` (~16 alerts; the patched releases require Go ≥ 1.23): - `cases/go/service`: `go 1.24`; x/crypto 0.46, x/net 0.48, grpc 1.79.3, protobuf 1.36.10; Dockerfile base `-go1.19` → `-go1.24`. `SW_AGENT_GO_COMMIT` → `19a9fa9` (the skywalking-go commit that ships the go1.24 images; go1.19 images were dropped). All 5 shared go cases (go/service, profiling/trace/go, pprof/{mysql,es,banyandb}) build from this one Dockerfile. - `cases/profiling/ebpf/network`: **migrated off the legacy go2sky SDK to the skywalking-go toolchain agent** (auto-instruments net/http server+client). The app exit span is now auto-instrumented (`GET:/provider`, `GoHttpClient`, layer `Http`, peer `proxy`, http tags, spanid 1/parent 0) — `expected/skywalking-trace.yml` updated, derived from the skywalking-go net/http plugin. The eBPF sampled-record name (`skywalking-<path>`) is network-derived and unchanged, so the verify query and the 4xx/5xx expectations are untouched.
1 task
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This clears the actionable, non-Go Dependabot alerts on
master. (The Go e2e-fixture alerts require a Go 1.24 agent toolchain and are handled separately via skywalking-go image work + an e2e follow-up.)Shipped product (oap-server-bom + LICENSE + docs)
4.3.0→5.9.0(+curator-test) and Apache ZooKeeper3.5.7→3.9.5, bumped together — Curator 5.x is the line that carries the ZK 3.9.x client. Clears CVE-2023-44981 (critical). OAP is a ZooKeeper client only, so the server-side bug was never reachable, but the bundled jar tripped Dependabot. The cluster-zookeeper and configuration-zookeeper plugins use only stable Curator APIs, so no source changes were required. Operator-facing change: supported ZooKeeper server version is now 3.5+ (3.4.x dropped by Curator 5.x).dist-material/release-docs/LICENSEregenerated (curator ×4, zookeeper + jute, audience-annotations);application.yml+backend-cluster.mdupdated.Build/test scope
3.20.2→3.27.7— clears CVE-2026-24400 (XXE inisXmlEqualTo, unused), test scope.e2e test fixtures (
test/e2e-v2, never shipped)32.0.0-jre, kafka-clients →3.9.2(+ removed a stale unused2.4.1property), log4j-core →2.25.4, logback →1.2.13(the Java-8 line, not Dependabot's JDK-111.4.12), json-path →2.9.0, flask →3.1.3, protobuf →4.25.8.Validation
clean installof the reactor (BOM change) ✓; cluster-zookeeper + configuration-zookeeper plugin tests ✓ on Curator 5.9.0 / ZK 3.9.5;java-test-servicee2e reactor compiles against the bumped deps ✓; checkstyle + license-header preflight ✓.CHANGESlog.