davsclaus commented on code in PR #26519:
URL: https://github.com/apache/camel/pull/26519#discussion_r4286222639
##########
parent/pom.xml:
##########
@@ -83,7 +83,7 @@
<azure-sdk-bom-version>1.3.3</azure-sdk-bom-version>
<azure-storage-blob-changefeed-version>12.0.0-beta.34</azure-storage-blob-changefeed-version>
<beanio-version>3.2.1</beanio-version>
- <bouncycastle-version>1.83</bouncycastle-version>
+ <bouncycastle-version>1.85</bouncycastle-version>
Review Comment:
The bump itself is fine. It is worth listing in the PR body what it fixes on
4.18.x, since that is why a dependency bump belongs on an LTS line:
- fixed in 1.85: CVE-2026-59649 (bcpg), CVE-2026-8763 (critical),
CVE-2026-13506
- fixed in 1.84: CVE-2025-14813 (critical), CVE-2026-3505, CVE-2026-5598,
CVE-2026-0636, CVE-2026-5588
A JIRA with fixVersion 4.18.6 (like CAMEL-25468 for 4.22.2) would also make
the change visible in the release notes.
##########
components/camel-pqc/src/main/java/org/apache/camel/component/pqc/lifecycle/FileBasedKeyLifecycleManager.java:
##########
@@ -531,15 +534,14 @@ private AlgorithmParameterSpec
getDefaultParameterSpec(String algorithm) {
try {
switch (algorithm) {
case "DILITHIUM":
- return
org.bouncycastle.pqc.jcajce.spec.DilithiumParameterSpec.dilithium2;
case "MLDSA":
+ return MLDSAParameterSpec.ml_dsa_44;
Review Comment:
This mapping is right. It does change what callers of the lifecycle managers
on 4.18.x can pass, though. `generateKeyPair()` now gets an ML-DSA (`BC`)
`KeyPairGenerator` for `DILITHIUM`, and BC 1.85's `MLDSAKeyPairGeneratorSpi`
only accepts ML-DSA parameter-set names. So the pattern the 4.18.x docs show,
```java
keyManager.generateKeyPair("DILITHIUM", "app-signing-key",
DilithiumParameterSpec.dilithium2);
```
now throws `InvalidAlgorithmParameterException: unknown parameter set name:
DILITHIUM2`. The same applies to `KyberParameterSpec` with `KYBER`. Keys stored
under 4.18.5 for `DILITHIUM`, `SPHINCSPLUS` or `KYBER` are reloaded through
`KeyFactory.getInstance("ML-DSA"/"SLH-DSA"/"ML-KEM", "BC")`, which does not
read the old encodings, so those keys have to be generated again.
None of this can be avoided with 1.85, since `BCPQC` no longer registers
these algorithms. Users should still learn about it from the upgrade guide
(`camel-4x-upgrade-guide-4_18.adoc` on `main`, *4.18.5 to 4.18.6*) rather than
from a failing route.
##########
components/camel-pqc/src/main/java/org/apache/camel/component/pqc/crypto/PQCDefaultSPHINCSPLUSMaterial.java:
##########
@@ -49,7 +49,7 @@ protected static KeyPairGenerator prepareKeyPair()
throws NoSuchAlgorithmException, NoSuchProviderException,
InvalidAlgorithmParameterException {
KeyPairGenerator kpGen =
KeyPairGenerator.getInstance(PQCSignatureAlgorithms.SPHINCSPLUS.getAlgorithm(),
PQCSignatureAlgorithms.SPHINCSPLUS.getBcProvider());
- kpGen.initialize(SPHINCSPlusParameterSpec.haraka_256s, new
SecureRandom());
+ kpGen.initialize(SLHDSAParameterSpec.slh_dsa_sha2_128s, new
SecureRandom());
Review Comment:
For the upgrade note: this also lowers the security level of the default
`SPHINCSPLUS` key material, from `haraka_256s` (NIST category 5) to
`slh_dsa_sha2_128s` (category 1). `main` uses the same default, so I would not
change it in this backport. It is worth one line in the 4.18.x upgrade-guide
entry, though, since anyone relying on the default gets a weaker key after a
patch upgrade. Users who need the higher level can switch to an SLH-DSA 256
parameter set.
--
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]
