Hello Hadoop users, I am currently upgrading an application to use hadoop-client-runtime:3.5.0 for HDFS access.
Our use case is limited to HDFS operations and SequenceFile reading and writing. During our security scan, we found that Hadoop 3.5.0 bundles the original JCraft JSch version 0.1.55. JSch 0.1.55 was released in 2018, so Hadoop 3.5.0, despite being a recent Hadoop release, includes a dependency that has not been updated for several years and belongs to the original, no longer actively maintained JCraft project. The classes are shaded inside hadoop-client-runtime under: org/apache/hadoop/shaded/com/jcraft/jsch/** The embedded Maven metadata identifies the dependency as: com.jcraft:jsch:0.1.55 Because JSch is already shaded into hadoop-client-runtime, a normal Maven exclusion does not remove it. Adding the maintained com.github.mwiede:jsch fork also does not replace the shaded classes used internally by Hadoop. Our vulnerability scanner reports this embedded 2018 dependency, and the finding currently blocks the release of our application, even though our application does not use Hadoop SSH, SFTP, or fencing functionality. Could you please clarify: 1. Is the inclusion of JSch 0.1.55 in hadoop-client-runtime:3.5.0 intentional? 2. Is there a plan to migrate from the original 2018 JCraft release to the actively maintained com.github.mwiede:jsch fork? 3. Could JSch be removed from hadoop-client-runtime, made optional, or moved to a separate artifact for users who actually require SSH, SFTP, or fencing functionality? 4. Is there an officially recommended workaround for applications that only use HDFS and do not need JSch? At the moment, the available workarounds appear to be: - downgrade the Hadoop Java client; - remove the shaded JSch classes when building the final application JAR; - build and maintain a custom Hadoop client runtime. None of these options is ideal for long-term maintenance. Thank you for your guidance and for your work on Apache Hadoop. Best regards, Sébastien.
