[
https://issues.apache.org/jira/browse/IO-71?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568559#action_12568559
]
David Smiley commented on IO-71:
--------------------------------
I agree with what you're saying. But as far as it being "not too much of an
issue"... I wonder if the risk isn't so much "normal expected data" but
instead a security concern resulting in a denial of service. Lets say
hypothetically that we had some decompressing outputstream. So if the input
size is X, then the output would generally be larger than X (and hence the
requirements of our buffer). In normal data the ratio might be a ratio of say
1:10 and since your code requests data in 1KB chunks, it'd need a 10KB buffer.
But an attacker might give this system data that has an extreme compression
ratio of say 1:100000000000 (lots of zeroes, whatever). Like say a 100MB file
consisting of all one's which would compress like mad. A system based on this
code would then consume all available memory and more or less crash. The size
of the input file needed to cause this to occur depends on both the deployed
environment and the compression ratio achievable.
I admit I'm sort of a perfectionist so I may be making a bigger deal out of
this than is warranted.
If you really do insist on a variation of your solution, I recommend you have
internal warning thresholds which cause warnings to be logged beyond certain
thresholds to alert people of a potential problem.
> [io] PipedUtils
> ---------------
>
> Key: IO-71
> URL: https://issues.apache.org/jira/browse/IO-71
> Project: Commons IO
> Issue Type: Improvement
> Components: Utilities
> Environment: Operating System: All
> Platform: All
> Reporter: David Smiley
> Priority: Minor
> Fix For: 2.x
>
> Attachments: PipedUtils.zip, ReverseFilterOutputStream.patch
>
>
> I developed some nifty code that takes an OutputStream and sort of reverses
> it as if it were an
> InputStream. Error passing and handling close is dealt with. It needs
> another thread to do the work
> which runs in parallel. It uses Piped streams. I created this because I
> had to conform
> GZIPOutputStream to my framework which demanded an InputStream.
> See URL to source.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
