oscerd commented on PR #28105: URL: https://github.com/apache/camel/pull/28105#issuecomment-6290175760
Rebased onto `main` and pushed the fix for the JDK 25 failure. **CI on JDK 25.** `KeyLifecycleParityTest.aCombinedPemExportCanBeImportedBack` and `aPublicOnlyPemStillRoundTrips` failed on the JDK 25 job only. From JDK 24 the JDK itself implements ML-DSA and ML-KEM (`SUN` provider) and is listed before BouncyCastle, so the provider-less `KeyFactory.getInstance(algorithm)` in `KeyFormatConverter` returned a `sun.security.pkcs.NamedPKCS8Key`. Its encoding equals the exported key's, but `equals` against the BouncyCastle key is false - and, more to the point, the component's BouncyCastle `Signature` rejects such a key with `unknown private key passed to ML-DSA`, so on JDK 24+ a key imported through the AWS Secrets Manager, Azure Key Vault, HashiCorp Vault or in-memory manager could not sign. The lookup was provider-less on `main` already; the new round-trip test is what exposed it. The commit "CAMEL-25801: camel-pqc - importKey resolves the KeyFactory with the BouncyCastle provider of the algorithm" resolves the provider the way `FileBasedKeyLifecycleManager.loadKeyPair` already does, through the component's algorithm tables (`BC`/`BCPQC`, by enum name or JCE name), and keeps the default lookup for an algorithm the component does not map or whose provider is not installed. The existing assertions are unchanged and now pass on both JDKs. The upgrade-guide note gained a bullet for it. **Rebase.** The only conflict was the 4.24 upgrade guide; the camel-pqc note now sits before the `camel-jbang - exit codes, and errors on stderr` section, at a different place from the other open camel-pqc PRs, so they stop conflicting with each other. **Verification:** camel-pqc on JDK 21 (`mvn clean install`) and on JDK 25 (`mvn test`: 283 tests, 0 failures); full reactor `mvn clean install -DskipTests -DskipITs` BUILD SUCCESS with no regenerated-file drift. _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]
