oscerd opened a new pull request, #27768: URL: https://github.com/apache/camel/pull/27768
Fixes [CAMEL-25603](https://issues.apache.org/jira/browse/CAMEL-25603). A KEM `KeyGenerator` keeps the spec passed to `init()` until `generateKey()` reads it, and a `KeyAgreement` keeps its state from `init()` to `generateSecret()`. Neither is thread-safe, but: - `PQCProducer` held one `KeyGenerator` for `generateSecretKeyEncapsulation` / `extractSecretKeyEncapsulation`, and one `KeyGenerator` plus one `KeyAgreement` for the hybrid KEM operations, for all exchanges. - `HybridKEM` ran the init-to-result sequences on whatever instances it was given. - `PQCDataFormat` cached one `KeyGenerator` at start, also when none was configured, and used it for every marshal and unmarshal. Overlapping exchanges could get a result computed from another exchange's parameters, or fail (`AEADBadTagException`, or a `NullPointerException` from the Bouncy Castle SPI). ## Change Same approach as CAMEL-24445 for `Signature`: - `PQCProducer` creates a new `KeyGenerator` / `KeyAgreement` for every exchange when it created them itself. It keeps the `Provider` object of the generator created at start, so creating another one does not depend on the provider still being registered (`PQCEndpoint.doStop()` removes the Bouncy Castle providers from the JVM). - A configured instance (an autowired registry bean, or the `PQCDefault*Material` defaults, which are shared JVM-wide) is used as-is, and each init-to-result sequence holds its monitor: in `PQCProducer`, in `HybridKEM` (so callers of the public utility are covered too) and in `PQCDataFormat`. - `PQCDataFormat` creates a `KeyGenerator` for every operation unless one is configured; `doStart()` still fails fast on an unknown algorithm or provider. As a side effect, the documented `CamelPQCKemAlgorithm` header now applies to a started data format. ## Tests New tests, all failing without the change: - `PQCKemSharedKeyGeneratorIsolationTest`: a configured `KeyGenerator` shared by a generate and an extract endpoint. Overlapping extractions, and an overlapping generation and extraction, each keep their own result. A small test helper (`InterleavingProbe`, with `ProbedKeyGenerator` / `ProbedKeyAgreement` wrappers) holds the first caller between `init()` and the result and records whether another `init()` got in. - `PQCKemConcurrentExtractionIsolationTest`: 8 threads x 40 extractions through one producer that created its own generator. - `HybridKEMConcurrencyTest`: overlapping extractions and encapsulations on a shared `KeyAgreement` and `KeyGenerator`. - `PQCDataFormatConcurrencyTest`: concurrent round trips through one data format with no `KeyGenerator` configured, and an overlapping marshal and unmarshal on a configured one. `camel-pqc`: 239 tests, 0 failures, 1 skipped (pre-existing). Full reactor `clean install -DskipTests -DskipITs`: BUILD SUCCESS (703 modules); the only regenerated files are the catalog copies of the two pqc docs. ## Docs - `pqc-component.adoc`: a note on how KEM `KeyGenerator` / `KeyAgreement` instances are used; registering a `KeyGenerator` bean is optional. - `pqc-dataformat.adoc`: the "Caching KeyGenerator" tip is replaced, since a shared instance now runs one operation at a time. - Upgrade guide notes for 4.24, 4.22.2 and 4.18.6, all on `main`. The change is meant to be backported to `camel-4.22.x` and `camel-4.18.x` (there is no hybrid KEM on 4.18.x). _Claude Code 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]
