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.