Uploaded image for project: 'Commons Compress'
  1. Commons Compress
  2. COMPRESS-386

Consider adding sanity check to maxCodeSize in ZCompressorInputStream

Attach filesAttach ScreenshotVotersWatch issueWatchersCreate sub-taskLinkCloneUpdate Comment AuthorReplace String in CommentUpdate Comment VisibilityDelete Comments
    XMLWordPrintableJSON

Details

    • Improvement
    • Status: Resolved
    • Minor
    • Resolution: Fixed
    • None
    • 1.14
    • None
    • None

    Description

      On TIKA-1631, several users pointed out that a bad value for the 4th byte of an apparently Z compressed file can lead to an OOM.

      If possible, it would be great to parameterize ZCompressorInputStream to set a threshold. Or, if this should be kept out of COMPRESS, is there some way that we could load a threshold-checking subclass of ZCompressorInputStream via the CompressorStreamFactory?

      Attachments

        Issue Links

        relates to

        Bug - A problem which impairs or prevents the functions of the product. COMPRESS-382 OutOfMemoryError from CompressorStreamFactory

        • Major - Major loss of function.
        • Resolved

        Bug - A problem which impairs or prevents the functions of the product. TIKA-1631 OutOfMemoryException in ZipContainerDetector

        • Major - Major loss of function.
        • Resolved

        Activity
          This comment will be Viewable by All Users Viewable by All Users
          Cancel

          People

            Unassigned Unassigned
            tallison Tim Allison
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Slack

                Issue deployment