Hi Penghui, Okay, that makes sense. So it should be the case that a topic might be produced by various producers with different encryption keys, the consumer side might want to differentiate messages from producers with different encryption keys.
Thanks, Yunze On Fri, Dec 5, 2025 at 10:31 AM PengHui Li <[email protected]> wrote: > > Hi Yunze, > > Thanks for bringing this to the discussion. I'm thinking it's probably > related to Pulsar support, encrypt data with different keys? > might the user want to get the encryption keys from the producer? > > Not pretty sure. > > Regards, > Penghui > > On Thu, Dec 4, 2025 at 4:54 AM Yunze Xu <[email protected]> wrote: > > > Hi all, > > > > The encryption context was introduced from > > https://github.com/apache/pulsar/pull/2024, which handles the case > > when decryption failed and the original encrypted payload to the > > application. > > > > However, even if the decryption succeeds, `Message#getEncryptionCtx` > > is still not empty, this results in an issue that the application has > > no way to know if the decryption failed. Hence, PIP-432 > > (https://github.com/apache/pulsar/pull/24481) was proposed to add a > > method `isEncrypted()` that indicates whether the message's data > > (`Message#getData`) is still encrypted (i.e. the decryption failed). > > > > When I'm trying to implement this feature on C++ client, I realized > > that this field is somehow unnecessary. If `getEncryptionCtx` returns > > an empty optional when the decryption succeeds, this field will not be > > needed anymore. > > > > The only question is if it's intentional to carry an encryption > > context when the decryption succeeds. For Java clients, I understand > > that it could bring breaking changes if we do so. But for other > > clients, it seems that we don't need to follow this "wrong" approach. > > > > WDYT? > > > > Thanks, > > Yunze > >
