oscerd opened a new pull request, #28089: URL: https://github.com/apache/camel/pull/28089
Fixes [CAMEL-25795](https://issues.apache.org/jira/browse/CAMEL-25795). ## Problem `PQCEndpoint.doStop()` unconditionally removed the `BC` and `BCPQC` providers from `java.security.Security`: ```java if (Security.getProvider(BouncyCastleProvider.PROVIDER_NAME) != null) { Security.removeProvider(BouncyCastleProvider.PROVIDER_NAME); } ``` `doStart()` only *adds* a provider when it is absent, so an endpoint routinely removed one it had not installed. `java.security.Security` is process-global, so this tears the provider out from under: - the sibling `pqc` endpoint of the same route — the canonical `pqc:sign` + `pqc:verify` pair in this component's own documentation breaks itself, since stopping one de-registers BC for the other; - other `CamelContext` instances in the same JVM; - camel-crypto, camel-crypto-pgp, camel-as2, camel-ssh, camel-xmlsecurity and the JSSE stack; - all non-Camel code in the JVM. After the removal, every `Signature.getInstance(..., "BC")` fails with `NoSuchProviderException`. The removal can also race with another thread that is mid-operation. CAMEL-22016 added the null guards but did not address provider *ownership*. ## Fix The providers are now left registered. Per-endpoint ownership tracking does **not** solve this — endpoint A adds the provider, endpoint B sees it present and skips, then A stops and removes it, breaking B. `Security` records no ownership and there is no reference counting across endpoints or across the JVM. Leaving them registered is also what the rest of the codebase already does: `camel-as2`, `camel-crypto-pgp` and this component's own 21 statically-initialised `PQCDefault*Material` classes all register BouncyCastle and never remove it. `PQCEndpoint` was the only place in the entire repository that removed a BouncyCastle provider. The now-empty `doStop()` override is removed, and the rationale is recorded on `doStart()`. ## Tests New `PQCEndpointProviderLifecycleTest`: - `stoppingTheContextKeepsTheProvidersRegistered` — both providers are still registered after `context.stop()`; - `stoppingOneEndpointLeavesTheOtherUsable` — a sibling `pqc` endpoint still works after the first one is removed. Both tests fail on `main` and pass with this change. Full `camel-pqc` module build is green: 241 tests, 0 failures, no regenerated-file drift. ## Note for reviewers Nearly every existing test in this module carries a `Security.addProvider(new BouncyCastleProvider())` in `@BeforeAll`. That workaround exists precisely because of this bug. Those blocks are now redundant, but removing ~90 of them is out of scope here — it is folded into CAMEL-25802. ## Upgrade guide Added a 4.24 entry: an application that relied on the providers being de-registered on shutdown must now remove them itself. --- _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]
