[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