[xmlsec] How to avoid the node passed to xmlSecEncCtxXmlEncrypt
to be released
Aleksey Sanin
aleksey at aleksey.com
Thu Mar 13 08:03:01 PST 2008
Thanks for the patch! I'll try to take a look over the weekend!
Aleksey
Frank Gross wrote:
> I attached the patch that allows the replaced nodes during encryption
> and decryption to be returned in the 'xmlSecEncCtxPtr' structure.
> Actually, I added two entries in the 'xmlSecEncCtrPtr' structure :
> - nodeReplacementMode, an enum of type 'xmlEncCtxNodeReplacementMode',
> to define if the nodes will be released or returned in the second entry,
> - a pointer to a xmlNodePtr called 'replacedNodeList' that contains the
> list of the nodes that have been replaced.
>
> One additional point, as it's up to the user to release the returned
> nodes, I'm not sure if the code I added in the 'xmlSecEncCtxReset'
> function to release the node list is necessary, because if someone
> releases the node but forget to set the pointer to NULL it will crash.
> But if he doesn't release the nodes, and this code is not there we got a
> memory leak.
>
> If you could take a look
>
> Thanks,
> Frank
>
> Aleksey Sanin a écrit :
>> Sure, I love patches :) BTW, you can't find any docs about
>> flags/flags2 in xmlSecEncCtx because they are not used at the moment :)
>> Just reserved for the future :)
>>
>> Aleksey
>>
>> Frank Gross wrote:
>>> Yes I agree, but it would be more efficient if I wouldn't have to do
>>> that. And I have the same problem when I try to encrypt only the
>>> content of an element, where all sub-nodes are removed. Actually, I
>>> try to write an API where you give the node to be encrypted, but the
>>> node passed to my function is still alive, and simply destroying the
>>> nodes inside the library is impossible in my case, because some other
>>> references can point on these nodes.
>>>
>>> Therefore may I suggest a request ? Could you add an option in the
>>> 'xmlSecEncCtxPtr' structure to specify how the nodes to be replaced
>>> should be handled, and return them in a list in the structure if for
>>> instance the option was set to not releasing them so that the user
>>> can choose to release them by hand or not. And the same kind of
>>> feature when decrypting a node, because in some cases you want to
>>> keep trace of the encrypted node.
>>>
>>> My 2 cents contribution that could really help in my case, and allow
>>> the programmer to choose instead of the library.
>>>
>>> If you agree I could make a patch, using flags or flags2 in the
>>> 'xmlSecEncCtxPtr' structure, and add a new entry of type xmlNodePtr
>>> with the list of nodes that were replaced but not released according
>>> to flags or flags2 value. BTW what is the difference between flags
>>> and flags2 ? Are they used because I didn't find any information in
>>> the documentation ?
>>>
>>> Best Regards,
>>>
>>> Frank
>>>
>>> Aleksey Sanin a écrit :
>>>> Well, you can always copy the node yourself before encrypting it.
>>>>
>>>> Aleksey
>>>>
>>>> Frank Gross wrote:
>>>>> Hi,
>>>>>
>>>>> I noticed that function 'xmlSecEncCtxXmlEncrypt' releases the node
>>>>> that was encrypted when replaced by the 'EncryptedData' node.
>>>>> Does it exist a way to not release that node, and let the user
>>>>> choose whether he wants to destroy it or not ?
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Frank
>>>>> _______________________________________________
>>>>> xmlsec mailing list
>>>>> xmlsec at aleksey.com
>>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
More information about the xmlsec
mailing list