Hmm. Nice pickup. This used to be fine because the interlocking was assumed to be required, so on the second run through, the actual manifest references would have "settled" and wouldn't change. Thus the setting of the overall manifest hash would work fine.

Of course, when I introduced the interlocking flag, that logic broke....

Thanks for that!  I will make this change in svn as well.

To actually answer your question - no I cannot see any other impact this would have - other than to make it work correctly :>.

Cheers,
        Berin

Peter Gubis wrote:

Hi,

I had problems with signing messages using manifest references. If signature element contains more than one manifest references, the digest of the last reference pointing to the last manifest object is not correctly calculated. After some debugging I found, that the digest in Reference node is calculated from Manifest node before the correct digest is inserted.

In xsec source code I found one recursive method, that calculates hashes for references and sets that hash to the proper place in the DOM structure. I think, that there is a bug, which firstly sets the hash of the reference and after that calculates hashes in referenced manifests.

In the file src\dsig\DSIGReference.cpp in method DSIGReference::hashReferenceList on line 855 you can see:

       for (int j = 0; j < i; ++j) {

           r = lst->item(j);

           r->setHash();

// If this is a manifest we need to set all the references in the manifest as well

           if (r->isManifest())
               hashReferenceList(r->getManifestReferenceList());

       }


I changed sequence to firstly calculate the hash in Manifests and just after that to set the hash of the reference node, and now it seems that it's working correctly.

Updated code:

       for (int j = 0; j < i; ++j) {

           r = lst->item(j);

// If this is a manifest we need to set all the references in the manifest as well

           if (r->isManifest())
               hashReferenceList(r->getManifestReferenceList());

           r->setHash();
       }


Now it seems, that both the hash of manifest and the hash of reference are correct. Either signature is processed correctly. Can this change have impact to another unexpected behavior of this method?


Thank you and best regards,
Peter.




Reply via email to