{
  "WorkItem": {
    "AffectedComponent": {
      "Name": "",
      "DisplayName": ""
    },
    "ClosedComment": "fixed in v1.8.4.31.  ",
    "ClosedDate": "2010-01-08T19:23:03.61-08:00",
    "CommentCount": 0,
    "Custom": null,
    "Description": "The Zlib implementation included with DotNetZip fails to decompress some data streams that were compressed using a predefined compression dictionary. When the library is extracting the dictionary checksum from the compressed data header, the checksum bytes are bitshifted, ANDed with a bitmask, and then assigned to a signed 64 bit long. During this operation, a 32 bit value is sign-extended when being converted to 64-bit, causing the returned checksum to be incorrect if the first bit of the checksum is 1. The decompression operation then fails due to the dictionary checksum in the stream not matching the calculated checksum of the dictionary supplied to the decompressor by the calling program.\n \nThis problem can be fixed by addition of a cast. I have attached a corrected version of Inflate.cs. From examining the code it also appears that a similar error may exist in the RFC1950 checksum handling in Inflate.cs (I have not attempted to fix it as I am not using that particular feature and do not have a test case that exposes the problem.)",
    "LastUpdatedDate": "2013-05-16T05:31:56.227-07:00",
    "PlannedForRelease": "",
    "ReleaseVisibleToPublic": false,
    "Priority": {
      "Name": "Low",
      "Severity": 50,
      "Id": 1
    },
    "ProjectName": "DotNetZip",
    "ReportedDate": "2010-01-07T07:22:01.017-08:00",
    "Status": {
      "Name": "Closed",
      "Id": 4
    },
    "ReasonClosed": {
      "Name": "Unassigned"
    },
    "Summary": "Zlib does not handle compression dictionaries properly",
    "Type": {
      "Name": "Issue",
      "Id": 3
    },
    "VoteCount": 1,
    "Id": 9945
  },
  "FileAttachments": [
    {
      "FileId": 2598,
      "FileName": "Inflate.cs",
      "DownloadUrl": ".\\2598"
    },
    {
      "FileId": 2602,
      "FileName": "Testcase.cs",
      "DownloadUrl": ".\\2602"
    }
  ],
  "Comments": [
    {
      "Message": "Hey thanks for the clear report.  Do you have a test case that I can use to demonstrate the problem? ",
      "PostedDate": "2010-01-07T12:14:38.69-08:00",
      "Id": -2147483648
    },
    {
      "Message": "On these changes, the port from ZLIB C-source to C# incorrectly translated a uLong in C (32 bits) to a long in C#. (64 bits).  The code you added casts to was particularly affected.  I've since combed over that code, and refined it quite a bit.  It now uses a uint for the variables you suggest using casts for. \r\n\r\nAs a result I'd like to be able to test the code to verify that the changes I made independently actually solve the problem you've seen. ",
      "PostedDate": "2010-01-07T12:33:13.267-08:00",
      "Id": -2147483648
    },
    {
      "Message": "I noticed the issue with the signed vs. unsigned types, but did not want to change it myself, as I (a) did not know whether the use of the long type was intentional and (b) the change could have caused effects elsewhere and I am not familiar with this code. Therefore I used the cast to fix only the places where it was failing for me. I agree that changing the types to unsigned is the \"right\" way to fix the bug.\r\n\r\nI can't send the original code that was causing the failure as it is part of a much larger project, but I put together a standalone test case that illustrates the problem.",
      "PostedDate": "2010-01-08T10:40:42.063-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2010-01-08T10:40:46.53-08:00",
      "Id": -2147483648
    },
    {
      "Message": "Thanks, jkovach, a small test case is fine.",
      "PostedDate": "2010-01-08T14:49:34.863-08:00",
      "Id": -2147483648
    },
    {
      "Message": "thank you again for the test case.   I ran it here and reproduced the problem on v1.8.  Also ran it against v1.9 and the problem does not occur.  So, you have your option: you can use v1.9, or you can wait for v1.8.4.31 for the v1.8 fix of this issue. ",
      "PostedDate": "2010-01-08T15:20:38.527-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2010-01-08T19:23:03.61-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-02-21T18:43:44.273-08:00",
      "Id": -2147483648
    },
    {
      "Message": "",
      "PostedDate": "2013-05-16T05:31:56.227-07:00",
      "Id": -2147483648
    }
  ]
}