DO NOT REPLY [Bug 33936] New: - XMLSignatureInput.updateOutputStream should not call reset on the inputstream

[bu...@apache.org]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG�
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://issues.apache.org/bugzilla/show_bug.cgi?id=33936>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND�
INSERTED IN THE BUG DATABASE.

http://issues.apache.org/bugzilla/show_bug.cgi?id=33936

           Summary: XMLSignatureInput.updateOutputStream should not call
                    reset on the inputstream
           Product: Security
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Signature
        AssignedTo: security-dev@xml.apache.org
        ReportedBy: rwong@ariba.com


This is for xmlsec version 1.2 Java. 

The defect is found in the reported configuration, but it should be a general 
defect across all platforms, all OS.

The input stream is returned by instances of 
org.apache.xml.security.utils.resolver.ResourceResolver. 
XMLSignatureInput.upateOutputStream calls the reset method here:

          } else {
            InputStream is = this._inputOctetStreamProxy;
            if (is.markSupported())
                is.reset();
                int num;
                bytes = new byte[1024];
                while ((num=is.read(bytes))>0) {
                	diOs.write(bytes,0,num);
                }
                
          }

Here's the problem:

For implementations of the resolve method where the input stream supports the 
mark operation, the implmentations may not have called the mark method before 
returning. And some implementation of InputStream can throw an IOException if 
the mark method is NOT called before the reset method is called. (An example is 
java.io.BufferedInputStream.) In this case, 
XMLSignatureInput.updateOutputStream throws an IOException, when in fact it 
could get the input stream data by simply reading the input stream. As a 
result, even though my implementation is passing in a valid InputStream, the 
core code throws an IOException when calling the reset method, and mistakenly 
thinks that my XMLSignatureInput instance is not available.

The workaround is for the implementation to make sure mark is called before 
returning the input stream.

But I think the design should be as follows:
The XMLSignatureInput class has no business of resetting the input stream 
becaus it does not if the input stream has been marked or not. The 
implementation of the resolve method should handle all the business of marking 
and resetting the input stream where appropriate.

The contract for the resolve call should be such that the implementation 
returns an XMLSignatureInput which contains a reference to the input stream 
which is ready to be consumed by the core code at whatever the current position 
in the input stream. The implementation can choose to always return a 
XMLSignatureInput that always references a new InputStream instance (in which 
case no mark or reset needs to be called), or the implementing class can choose 
to cache the input stream, mark it, and then calls reset every time the resolve 
method is called.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.