Yicong-Huang opened a new pull request, #6203: URL: https://github.com/apache/texera/pull/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`). ### Any related issues, documentation, discussions? Backports apache/texera#6201 (merged to `main`), which resolves #6200. 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`). 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) -- 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]
