oscerd opened a new pull request, #28091: URL: https://github.com/apache/camel/pull/28091
Fixes [CAMEL-25799](https://issues.apache.org/jira/browse/CAMEL-25799). ## Problem `PQCComponent.configureHybridSignatureMaterial()` guards on the **classical** material being unset, but the body overwrites the **PQC** material: ```java if (ObjectHelper.isEmpty(configuration.getClassicalSigner()) && ObjectHelper.isEmpty(configuration.getClassicalKeyPair())) { ... if ("ECDSA_P256".equals(classicalAlg) && "MLDSA".equals(pqcAlg)) { configuration.setClassicalSigner(PQCDefaultECDSAMLDSAMaterial.classicalSigner); configuration.setClassicalKeyPair(PQCDefaultECDSAMLDSAMaterial.classicalKeyPair); configuration.setSigner(PQCDefaultECDSAMLDSAMaterial.pqcSigner); // <-- overwrites configuration.setKeyPair(PQCDefaultECDSAMLDSAMaterial.pqcKeyPair); // <-- overwrites ``` An earlier block correctly guards the PQC half, but this one then overwrites what it preserved. A route configured as `hybridSign&signatureAlgorithm=MLDSA&classicalSignatureAlgorithm=ECDSA_P256` with its own `keyPair` bean signs with the shared static demo key instead, and verification against the real public key fails with nothing in the log to explain it. `configureHybridKEMMaterial()` has the same shape for `keyGenerator` and `keyPair`. ## Fix Whether the route author supplied the PQC material is captured **before** any auto-configuration runs, and the pre-built hybrid materials only replace the PQC half when it was absent: ```java boolean pqcMaterialMissing = ObjectHelper.isEmpty(configuration.getSigner()) && ObjectHelper.isEmpty(configuration.getKeyPair()); ``` Capturing it up front rather than re-testing in place preserves the existing intent: when nothing was supplied, the first block's generic default is still replaced by the *matched* classical+PQC pair, which is the point of the pre-built materials. ## Tests New `PQCHybridKeyPairPreservedTest`: - `hybridSignKeepsTheConfiguredPqcKeyPair` - `hybridKemKeepsTheConfiguredPqcKeyPair` - `hybridSignStillAutoConfiguresWhenNothingIsSupplied` — guards the behaviour that must not change The first two fail against `main` with `expected: <KeyPair@43c87306> but was: <KeyPair@14f40030>`; the third passes both ways. Full `camel-pqc` build green: 242 tests, 0 failures, no regenerated-file drift. ## Note for reviewers — an autowiring collision worth a separate look `keyPair` and `classicalKeyPair` are **both** `@Metadata(autowired = true)` (`PQCConfiguration` lines 39-41 and 90-92), as are `signer`/`classicalSigner` and `keyGenerator`/`classicalKeyAgreement`. A registry holding one `KeyPair` bean has it autowired into both halves, so an ML-DSA key pair silently becomes the classical ECDSA key pair and fails at signing time. It also masked this bug: with `classicalKeyPair` autowired, the classical branch is skipped entirely. The first version of this test passed against unpatched code for exactly that reason, which is why it now sets `context.setAutowiredEnabled(false)`. Not addressed here — this PR is scoped to the guard — but the collision looks unintended. --- _Reported, analysed and fixed by Claude Code (AI agent) on behalf of @oscerd._ 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- 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]
