Andrea Cosentino created CAMEL-26549:
----------------------------------------
Summary: camel-ftp - SFTP cannot negotiate the post-quantum key
exchange on Java 17 and 21 because Bouncy Castle is test scoped
Key: CAMEL-26549
URL: https://issues.apache.org/jira/browse/CAMEL-26549
Project: Camel
Issue Type: Bug
Components: camel-ftp
Reporter: Andrea Cosentino
Assignee: Andrea Cosentino
jsch 2.28.7 proposes {{mlkem768x25519-sha256}} first in its default key
exchange list, but it implements ML-KEM in one of two ways: through the JDK 24+
multi-release classes
({{META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class}}) or through Bouncy
Castle ({{com/jcraft/jsch/bc/MLKEM.class}}).
{{camel-ftp}} declares {{bcpg-jdk18on}} and {{bcpkix-jdk18on}} with
{{<scope>test</scope>}}, so on a Java 17 or 21 runtime there is no ML-KEM
implementation on the classpath, jsch drops the group from its proposal and the
connection falls back to classical ECDH without a word. The main build runs on
Java 25, where the multi-release path works, so no test catches it.
{{camel-ssh}} is not affected: sshd 2.20 ships {{mlkem768x25519-sha256}},
{{mlkem768nistp256-sha256}}, {{mlkem1024nistp384-sha384}} and
{{sntrup761x25519-sha512}} in {{BuiltinDHFactories}}, its ML-KEM implementation
is Bouncy Castle based, and camel-ssh has BC at compile scope.
Neither component documents the post-quantum key exchange, nor the
{{keyExchangeProtocols}} (sftp) and {{kex}} (ssh) values needed to pin or
verify it - and a user who pinned {{kex}} years ago is silently stuck on
classical.
--
This message was sent by Atlassian Jira
(v10.3.26#10030026)
