Re: [xml] C14N issue with digital signature due to pointer comparison

Ok, I understand the need of speed, but there is still something that worries me. This means that the Canonicalization process depends then on the way the XML document is in memory. For instance, if I load a XML document from disk and canonicalize it, or build the same document in memory from scratch with node built maybe from copy or clone of another document in memory, the Canonicalization result can be different, even if document saved on disk would be the same.

But ok, I will fix it in my code

Thanks a lot,

Le 20/03/2014 15:04, Aleksey Sanin a écrit :
The tradeoff here is speed. Again, if you are using standard LibXML2
API then everything will work as expected. I have no idea why do you
need to create new xmlNsPtr objects - this sounds like a waste of
CPU/memory to me but you might have your reasons. But this also breaks
a few assumptions on how LibXML2 represents the DOM tree in memory
and you are on your own in this case.


On 3/20/14, 1:26 AM, Frank Gross wrote:

  Actually, I have an additional layer to emulate DOM compliant API over
libxml. In that layer, I have a global list of xmlNsPtr for all
namespaces encountered by the nodes (and referenced in node->ns) of a
single XML document. And for each namespace definition (xmlns:xxx) set
on a node, a new xmlNsPtr is created and referenced in node->nsDef.  So
during canonicalization process, when a node looks for a parent
namespace definition via xmlSearchNs, it can happen that the xmlNsPtr
reference from the node is different from the parent node->nsDef , even
if the href and prefix value are the same. Then of course simple pointer
comparison doesn't work. So I was asking myself if such situation cannot
happen to other people, and maybe change the pointer comparison because
depending on how people build and manipulate the document, the test is
not always accurate.


Le 20/03/2014 03:16, Aleksey Sanin a écrit :
How do you manipulate the XML tree? If you are using "official" LibXML2
function then I believe this code should work just fine unless there is
a bug in the strings dictionary.


On 3/12/14, 10:28 AM, Frank Gross wrote:

    I'm getting some trouble to verify a XML signature because the
xmlC14NProcessNamespacesAxis() function does a xmlNsPtr pointer
comparison to decide whether a sub node belongs to the same default
namespace as an ancestor. But if the sub node has been manipulated by
program (in my case) to point to another xmlNsPtr with same values, the
canonicalization process breaks. Wouldn't it be better to check the
namespace href values instead as in following patch ?

diff --git a/lib-xmlsoft-libxml2/src/c14n.c
index 9c3cad2..f73e709 100644
--- a/lib-xmlsoft-libxml2/src/c14n.c
+++ b/lib-xmlsoft-libxml2/src/c14n.c
@@ -623,7 +623,7 @@ xmlC14NProcessNamespacesAxis(xmlC14NCtxPtr ctx,
xmlNodePtr cur, int visible)
       for(ns = n->nsDef; ns != NULL; ns = ns->next) {
           tmp = xmlSearchNs(cur->doc, cur, ns->prefix);

-        if((tmp == ns) && !xmlC14NIsXmlNs(ns) && xmlC14NIsVisible(ctx,
ns, cur)) {
+        if((xmlStrEqual(tmp->href,ns->href)) &&
(xmlStrEqual(tmp->prefix,ns->prefix)) && !xmlC14NIsXmlNs(ns) &&
xmlC14NIsVisible(ctx, ns, cur)) {
           already_rendered = xmlC14NVisibleNsStackFind(ctx->ns_rendered,
           if(visible) {
                   xmlC14NVisibleNsStackAdd(ctx->ns_rendered, ns, cur);


Software Engineer - Web Services
Four J's Development Tools -

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]