[ 
https://issues.apache.org/jira/browse/CAMEL-26588?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Andrea Cosentino reassigned CAMEL-26588:
----------------------------------------

    Assignee: Andrea Cosentino

> camel-pqc - the stateful key claim is released by the first producer to stop, 
> and locks the key id rather than the key
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: CAMEL-26588
>                 URL: https://issues.apache.org/jira/browse/CAMEL-26588
>             Project: Camel
>          Issue Type: Bug
>          Components: camel-pqc
>            Reporter: Andrea Cosentino
>            Assignee: Andrea Cosentino
>            Priority: Major
>
> Follow-up to CAMEL-26547, which introduces a {{FileLock}}-based claim so that 
> only one process signs with a stateful key. Two lifecycle problems are 
> deliberately left out of that issue to keep its change reviewable, and are 
> tracked here.
> h3. 1. The claim is released by the first producer to stop
> {{claimedStatefulKeys}} is a field of {{PQCProducer}}, while 
> {{statefulClaims}} is a field of the {{KeyLifecycleManager}}. Two producers 
> sharing one manager each track their own claimed set, but the manager holds a 
> single {{FileChannel}} per key id. When the first producer stops, its 
> {{doStop}} calls {{releaseStatefulKey}}, which closes that shared channel - 
> so the remaining producers keep signing while the claim they rely on is gone.
> A per-key reference count in the manager, released only by the last holder, 
> would fix it.
> h3. 2. The claim locks the key id, not the key
> The lock file is named from the {{CamelPQCKeyId}} header:
> * an exchange carrying a different header value claims a different lock file, 
> while signing with the same endpoint {{keyPair}};
> * an exchange carrying no header skips the claim entirely.
> So the lock does not actually bind to the key material it is meant to 
> protect. Deriving the lock name from a fingerprint of the public key would 
> tie the two together, and would also give the no-header case something to 
> lock.
> Both were raised by [~davsclaus] while reviewing 
> https://github.com/apache/camel/pull/29098.
> ----
> _Reported by Claude Code (AI agent) on behalf of [~oscerd]._



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to