oscerd opened a new pull request, #29098: URL: https://github.com/apache/camel/pull/29098
## Motivation XMSS, XMSSMT, LMS and HSS are one-time-signature schemes: signing twice from the same index breaks the key. CAMEL-25796 made the index durable within one JVM. But the index lives *inside the private key*, so two processes that load the same key from a shared store — two pods on one volume, two replicas reading one vault secret — each advance their own copy and hand out the same index. Nothing stood in the way of that: - `FileBasedKeyLifecycleManager` took no lock on the key file. - The vault-backed managers make the situation *more* likely, not less: a shared vault is the normal way two replicas end up with the same key. - `pqc-key-lifecycle.adoc` said "never reuse a stateful signature state (critical security requirement)" and then said concurrent key operations are safe — true in-process only, with no mechanism and no warning for the multi-process case. ## Changes - `KeyLifecycleManager` gains `claimStatefulKey(String)` and `releaseStatefulKey(String)`, both `default` so a custom manager still compiles. The default grants no claim. - `FileBasedKeyLifecycleManager` takes an exclusive `FileLock` on a `<keyId>.lock` file in the key directory, resolved through the existing `resolveKeyFile` confinement (CAMEL-24937), with owner-only permissions. The lock lives as long as the channel, so the OS releases it if the holder dies. - `InMemoryKeyLifecycleManager` grants the claim — its keys never leave the process. - `PQCProducer` claims the key before its first stateful signature (both the plain and the hybrid sign paths) and releases on stop. A refused claim fails the exchange *before* the index is consumed. - New `allowSharedStatefulKey` option (default `false`) for a deployment whose single signer is guaranteed elsewhere — one replica, an external lock, a leader election. It warns once per key. - Docs: a "Single Ownership of a Stateful Key" section with a per-manager table, and the thread-safety section now says what it actually covers. - Upgrade guide entry for 4.24. ## Compatibility **This fails closed**: an endpoint signing with a stateful key through AWS Secrets Manager, Azure Key Vault or Hashicorp Vault now fails with a message naming the key and the opt-in. That is deliberate — a reused one-time index is unrecoverable, and the alternative is a silent key-destroying footgun. Unchanged: the stateless algorithms, all KEM operations, and a stateful endpoint with no `KeyLifecycleManager` (which persists no index at all and keeps its existing warning). `allowSharedStatefulKey` carries `security = "insecure:dev"`, so the build registered it in `SecurityUtils` and `camel.main.profile=prod` reports it. None of the four existing categories is a perfect fit; `insecure:dev` is the closest, and having the opt-in governed by the policy framework seems right. Say the word if you'd rather it carried no category. ## Testing - `FileBasedKeyLifecycleManagerStatefulClaimTest`: the claim is granted and visible as a lock file; re-claiming by the same manager is idempotent; a second manager over the same directory is refused; a released key can be taken by the next owner; releasing an unclaimed key is a no-op; a `keyId` that escapes the directory is still rejected. - `PQCStatefulKeyClaimTest`: a stateful key a manager cannot claim is refused with an actionable message and publishes no signature; `allowSharedStatefulKey=true` signs anyway; a stateless ML-DSA key is never claimed. - Full `camel-pqc` suite: 334 tests, 0 failures. Full reactor build green. --- _Claude Code on behalf of @oscerd_ -- 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]
