davsclaus commented on code in PR #28099: URL: https://github.com/apache/camel/pull/28099#discussion_r4325620351
########## docs/user-manual/modules/ROOT/pages/camel-4x-upgrade-guide-4_24.adoc: ########## @@ -294,6 +303,40 @@ local model gets a core set of tools (`--tools=auto`, the default), a hosted mod of `--max-iterations` is now 25 instead of 10, and `--model llama3.2` now selects that model also when a model better at tool calling, such as `qwen3.6`, is installed. +=== camel-pqc - the usage-count and PENDING_ROTATION key rotation signals now fire + +Two of the three documented rotation signals of `KeyRotationScheduler` previously never triggered. Both now work, so a +deployment that already configured them will start rotating keys where before nothing happened. + +* `maxKeyUsage` (and `camel.component.pqc.key-rotation-max-usage`) read `usageCount`, which was only advanced for the + stateful signature algorithms (XMSS, XMSSMT, LMS, HSS). For ML-DSA, SLH-DSA, Falcon and the KEM keys the counter + stayed at zero forever. A signing operation now advances it for every key, provided a `keyLifecycleManager` is + configured and the exchange carries a `CamelPQCKeyId` header. +* The scheduler's default key filter accepted only `ACTIVE` keys, so a key an operator had marked + `PENDING_ROTATION` was skipped before `needsRotation()` was consulted. The default filter now accepts `ACTIVE` and + `PENDING_ROTATION`. A custom filter set with `setKeyFilter` is unaffected. + +Review any configured `maxKeyUsage` threshold before upgrading: a long-running deployment may rotate on the first +check once the counter starts advancing. + +=== camel-pqc - a failed stateful signature no longer carries the signature headers + +Signing with one of the stateful hash-based algorithms (LMS, HSS, XMSS, XMSSMT) consumes a one-time index inside the +private key. That advanced key is now persisted through the `keyLifecycleManager` *before* the signature is placed on +the message, instead of after. + +Such an exchange already failed when the key state could not be stored, so what changes is the content of the failed +message: it no longer carries `CamelPQCSignature`, nor the hybrid `CamelPQCHybridSignature`, +`CamelPQCClassicalSignature` and `CamelPQCPqcSignature` headers. A route that caught the failure with +`onException(...).handled(true)`, or routed it to a dead letter channel, could previously read the signature off the +failed message and pass it on; it can no longer do so. That is the point of the change - a signature whose index +advance was never recorded must not escape, because after a restart the key resumes at the previous index and can +sign a second time with an index already used. + +Signing without a `keyLifecycleManager`, without a `CamelPQCKeyId` header, or with no stored metadata for the key, Review Comment: Nit: with no `keyLifecycleManager`, only a stateful key warns (the code returns early otherwise, on purpose). As written, this reads as if every key warns in all three cases. Maybe: "Signing a stateful key without a `keyLifecycleManager`, and signing any key without a `CamelPQCKeyId` header or without stored metadata, now logs a warning once per producer ..." -- 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]
