oscerd opened a new pull request, #29094: URL: https://github.com/apache/camel/pull/29094
## Motivation Both SSH stacks Camel ships already propose a hybrid post-quantum key exchange ahead of the classical groups, and neither could actually perform one: - jsch 2.28.7 puts `mlkem768x25519-sha256` first in its default kex list, and implements ML-KEM either through its JDK 24+ multi-release classes (`META-INF/versions/24/com/jcraft/jsch/jce/MLKEM.class`) or through the Bouncy Castle lightweight API (`com/jcraft/jsch/bc/MLKEM.class`). - Apache MINA SSHD 2.20 has `mlkem768x25519-sha256`, `mlkem768nistp256-sha256`, `mlkem1024nistp384-sha384` and `sntrup761x25519-sha512` in `BuiltinDHFactories`, and `org.apache.sshd.common.kex.MLKEM` is written against `org.bouncycastle.crypto`. `camel-ftp` (jsch) and `camel-mina-sftp` (sshd-sftp) declared Bouncy Castle with `<scope>test</scope>` only. On the Java 21 baseline there is therefore no ML-KEM implementation on the **runtime** classpath: the group is dropped from the proposal and the connection falls back to classical ECDH silently. The build runs on Java 25, where jsch takes its multi-release path, so no test saw it. ## Changes - `bcprov-jdk18on` is a compile dependency of `camel-ftp` and `camel-mina-sftp`. Only `bcprov` is needed — both stacks use the lightweight `org.bouncycastle.crypto` API, not the JCE provider. - `camel-jsch` (scp) depends on `camel-ftp` at compile scope and picks it up from there. `camel-ssh` was already fine: it has `bcpg`/`bcpkix` at compile scope, which pull `bcprov`. - Documentation for `sftp`, `mina-sftp` and `ssh` now covers the post-quantum exchange, including something none of them said: **`keyExchangeProtocols` (and `kex`) replace the proposal rather than adding to it**, so an endpoint that pinned a list of classical algorithms years ago never negotiates a post-quantum one. The `mina-sftp` available-protocols table was missing the four hybrids entirely. - Upgrade guide entry for 4.24. ## Testing - New `SftpPostQuantumKeyExchangeIT` (camel-ftp): asserts jsch leads its default proposal with the hybrid group, and performs a real transfer against the embedded server with the proposal pinned to `mlkem768x25519-sha256` — which can only succeed if ML-KEM is genuinely available. - New case in `SftpKeyExchangeProtocolsIT` (camel-mina-sftp) doing the same through sshd. - Both pass on Java 21. Full reactor build green. **One caveat, stated plainly:** these ITs cannot catch the regression they describe. Bouncy Castle was already on the *test* classpath of both modules, so they would have passed before this change too. They guard the feature; the fix itself is verified with `mvn dependency:tree` showing `bcprov-jdk18on:compile` rather than `:test`. ## Tradeoff This adds `bcprov` (~8 MB) to the runtime classpath of every `camel-ftp` and `camel-mina-sftp` user, and it becomes redundant for jsch once the Java baseline reaches 24. The alternative is `<optional>true</optional>` plus a documentation note, which keeps the footprint but leaves the default silently classical. I went with secure-by-default; happy to switch if you prefer the optional dependency. --- _Claude Code on behalf of @oscerd_ -- 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]
