You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by bu...@apache.org on 2003/10/02 02:28:39 UTC
DO NOT REPLY [Bug 23554] New: -
ResolverFragment.engineResolve should fail when IdResolver cannot resolve the fragment
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23554>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND
INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23554
ResolverFragment.engineResolve should fail when IdResolver cannot resolve the fragment
Summary: ResolverFragment.engineResolve should fail when
IdResolver cannot resolve the fragment
Product: Security
Version: C++ 0.20
Platform: Other
OS/Version: Other
Status: NEW
Severity: Normal
Priority: Other
Component: Signature
AssignedTo: security-dev@xml.apache.org
ReportedBy: rwong@ariba.com
The following code instantiates a HelperNodeList if IdResolver.getElementById
returns null. This can happen in situations where the fragment corresponding to
the Reference URI is missing from the doc, and any registered Resource
resolvers do not know how to resolve this reference (because for example it
really is an unknown resource). The correct behavior in this case I believe
would be for XMLSignature.sign() to throw an XMLSignatureException. But the
code below actually would instantiate a HelperNodeList and use its bytes as the
XMLInputSource for the digest to be generated. As a result, signing succeeds
(where it really should fail). I think the code should throw an exception
instead of doing a new HelperNodeList().
// Element selectedElem = doc.getElementById(id);
Element selectedElem = IdResolver.getElementById(doc, id);
// cat.debug("Try to catch an Element with ID " + id + " and Element
was " + selectedElem);
if (selectedElem == null) {
resultNodes = new HelperNodeList();
} else {
...
}