The GitHub Actions job "Required Checks" on texera.git/release/v1.2 has succeeded. Run started by GitHub user Yicong-Huang (triggered by Yicong-Huang).
Head commit for run: 0059bea8af89607a036f9dc7061c9a0e07ba0cb7 / Yicong Huang <[email protected]> fix(deps, v1.2): upgrade Apache Hadoop to 3.4.3 to resolve hadoop-common CVEs (#6203) ### What changes were proposed in this PR? Backport of apache/texera#6201 to `release/v1.2`: upgrade `org.apache.hadoop:hadoop-common` to 3.4.3 in both places it is pinned (`common/workflow-core/build.sbt` was at 3.3.1, `amber/build.sbt` at 3.3.3), and upgrade `hadoop-mapreduce-client-core` to 3.4.3 alongside it with hadoop 3.4's new direct `netty-all` dependency excluded. This resolves the same 4 Dependabot alerts on `hadoop-common` for the release line: - [#656](https://github.com/apache/texera/security/dependabot/656) CVE-2022-25168 (critical, argument injection in `FileUtil.unTar`, fixed in 3.3.3) - [#732](https://github.com/apache/texera/security/dependabot/732) CVE-2022-26612 (critical, fixed in 3.3.3) - [#654](https://github.com/apache/texera/security/dependabot/654) CVE-2021-37404 (critical, heap overflow in libhdfs, fixed in 3.3.2) - [#700](https://github.com/apache/texera/security/dependabot/700) CVE-2024-23454 (low, fixed in 3.4.0) Cherry-pick of 1094a6569 with conflicts resolved: - `common/workflow-core/build.sbt`: took only this PR's `excludeNetty` addition; the adjacent `log4jVersion` line in the conflict hunk belongs to #6199, which is not on `release/v1.2` (its backport #6202 is separate and still open). - The 8 `LICENSE-binary`(-java) / `NOTICE-binary` manifests were **regenerated from freshly built `release/v1.2` dists** rather than taken from `main`, because `main`'s manifests reflect deps this branch does not have: the log4j 2.26.1 bridge entries (from #6199) are removed, and pekko stays 1.2.1 (main: 1.6.0), ssl-config-core 0.6.1 (main: 0.7.1), slf4j-api 2.0.16 (main: 2.0.17). `NOTICE-binary` files were regenerated with `generate_notice_binary.py` (amber with `--extras amber/NOTICE-binary-python`). **Update:** this PR also folds in the startup-regression fix from apache/texera#6205 (issue #6204), so the hadoop upgrade lands on `release/v1.2` without ever breaking service startup. Hadoop 3.4 ships Jersey 1's JSON module via the fork `com.github.pjfanning:jersey-json`, which the existing `com.sun.jersey` exclusion rules do not catch; its `META-INF/services` entries register Jersey 1.x providers whose superclasses live in the (excluded) jersey-core 1.x, so Dropwizard's Jersey 2 `ServiceFinder` dies with `NoClassDefFoundError: com/sun/jersey/core/provider/jaxb/AbstractRootElementProvider` on boot. The fix excludes `com.github.pjfanning:jersey-json` from the hadoop dependencies in `common/workflow-core/build.sbt` and `amber/build.sbt`, and removes the two jars that consequently leave the dists (`jersey-json-1.22.0`, its transitive `jaxb-impl-2.2.3-1`) from the four `LICENSE-binary`(-java) manifests, regenerated against dists rebuilt on this branch. ### Any related issues, documentation, discussions? Backports apache/texera#6201 (merged to `main`), which resolves #6200. Also includes the fix from apache/texera#6205 for #6204 (startup regression introduced by #6201). No `release/*` label is added — this PR *is* the backport. ### How was this PR tested? Binary licensing manifests were verified the same way CI checks them: built the four affected dists on this branch (`sbt WorkflowExecutionService/dist FileService/dist ComputingUnitManagingService/dist WorkflowCompilingService/dist`), then ran `check_binary_deps.py` in strict (nightly) mode against each unzipped dist — all four pass (`OK: 395/300/337/312 JVM jars match LICENSE-binary`). For the folded-in #6205 fix: rebuilt all four dists on this branch after adding the exclusion and verified via `unzip -l` that `jersey-json` and `jaxb-impl` are no longer bundled in any of them; `check_binary_deps.py` re-run against the fresh dists passes for all four services (`OK: 393/298/310/335 JVM jars match LICENSE-binary`), and `generate_notice_binary.py` reports no `NOTICE-binary` drift (the removed jars carry no NOTICE entries). On `main` the same exclusion was verified end to end: `texera-web` reproducibly crashes on boot without it and starts cleanly with it (Jetty up on :8080). Tested with existing test cases: - `sbt WorkflowCore/test`: 294 tests passed, 0 failed. (4 suites — `S3StorageClientSpec` and the `LargeBinary*` specs — abort because they need an external MinIO service; verified they abort identically on unmodified `release/v1.2`, unrelated to this change.) - `sbt WorkflowExecutionService/Test/compile` passes (95 test sources; `SequentialRecordStorageSpec`, run on `main` for the `HDFSRecordStorage` path, does not exist on `release/v1.2` — `HDFSRecordStorage` itself compiles against hadoop 3.4.3). - `sbt "WorkflowCore/testOnly *IcebergUtilSpec"` (Iceberg + hadoop `Configuration` usage): 14 tests passed. (`DocumentFactorySpec` from the original PR's test list also does not exist on `release/v1.2`.) ### Was this PR authored or co-authored using generative AI tooling? Generated-by: Claude Code (Claude Fable 5) --------- Co-authored-by: Claude Fable 5 <[email protected]> Co-authored-by: Xinyuan Lin <[email protected]> Report URL: https://github.com/apache/texera/actions/runs/28819595930 With regards, GitHub Actions via GitBox
