starred/sharpcompress
1
0
Fork 0
mirror of https://github.com/adamhathcock/sharpcompress.git synced 2026-02-03 21:23:38 +00:00
Code Issues 975 Packages Projects Releases 20 Wiki Activity

[PR #118] [MERGED] Bugfix for inflate algorithm cutting of the end of certain blocks #846

New Issue
Open
opened 2026-01-29 22:17:51 +00:00 by claunia · 0 comments
claunia commented 2026-01-29 22:17:51 +00:00
Owner
Copy Link

📋 Pull Request Information

Original PR: https://github.com/adamhathcock/sharpcompress/pull/118
Author: @kenkendk
Created: 1/22/2016
Status: ✅ Merged
Merged: 1/23/2016
Merged by: @adamhathcock

Base: master ← Head: master

📝 Commits (2)

  • d5c88eb Bugfix for inflate algorithm cutting of the end of certain blocks
  • ecceec8 Tabs -> spaces fix

📊 Changes

1 file changed (+10 additions, -0 deletions)

View changed files

📝 SharpCompress/Compressor/Deflate/Inflate.cs (+10 -0)

📄 Description

After tracking down a case of a corrupt file being extracted, I was able to isolate the issue to a single 100kb file. If I compress this file with the maximum compression, and decompress it, I the loose the trailing 109 bytes.

I have finally tracked down the issue and made this patch. The problem is that the number of bits requested is larger than the number of bits required. For the LEN and DIST case, the number of required bits k is set to lbits and dbits respectively. But if you look in the code below, you can see that they "consume" a variable number of bits, which in this case is less than k.

For most cases this is not a problem, but when the last code to be processed hits this case, the decompression stops prematurely and this cuts of a number of bytes. Other zip implementations (unarchiver, 7zip, etc) handles this correctly. This bug is also present in jzlib and the DotNetZip libraries, but not in the SharpZipLib/ICSharp.ZipLib.

If have a file that can reproduce this, but I am awaiting clarification to see if I can provide publicly it.

As a side note, the inflater file contains some of the worst code I have seen. It is a mix of states stored in objects and scope, copied around. There are almost no comments, tens of single digit variables, and the control flow is ridiculously hard to follow. In many places the same code is simply copy-pasted rather than being encapsulated, which is why there are two changes to the source code. In other words: if you have another zip implementation, I suggest you go with that :).

🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.

## 📋 Pull Request Information **Original PR:** https://github.com/adamhathcock/sharpcompress/pull/118 **Author:** [@kenkendk](https://github.com/kenkendk) **Created:** 1/22/2016 **Status:** ✅ Merged **Merged:** 1/23/2016 **Merged by:** [@adamhathcock](https://github.com/adamhathcock) **Base:** `master` ← **Head:** `master` --- ### 📝 Commits (2) - [`d5c88eb`](https://github.com/adamhathcock/sharpcompress/commit/d5c88ebab3293658f0c1ac331a868227e9353fa4) Bugfix for inflate algorithm cutting of the end of certain blocks - [`ecceec8`](https://github.com/adamhathcock/sharpcompress/commit/ecceec8e1a9771499931f9ff33518174875ce16f) Tabs -> spaces fix ### 📊 Changes **1 file changed** (+10 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `SharpCompress/Compressor/Deflate/Inflate.cs` (+10 -0) </details> ### 📄 Description After tracking down a case of a corrupt file being extracted, I was able to isolate the issue to a single 100kb file. If I compress this file with the maximum compression, and decompress it, I the loose the trailing 109 bytes. I have finally tracked down the issue and made this patch. The problem is that the number of bits requested is larger than the number of bits required. For the `LEN` and `DIST` case, the number of required bits `k` is set to `lbits` and `dbits` respectively. But if you look in the code below, you can see that they "consume" a variable number of bits, which in this case is less than `k`. For most cases this is not a problem, but when the last code to be processed hits this case, the decompression stops prematurely and this cuts of a number of bytes. Other zip implementations (unarchiver, 7zip, etc) handles this correctly. This bug is also present in jzlib and the DotNetZip libraries, but not in the SharpZipLib/ICSharp.ZipLib. If have a file that can reproduce this, but I am awaiting clarification to see if I can provide publicly it. As a side note, the inflater file contains some of the worst code I have seen. It is a mix of states stored in objects and scope, copied around. There are almost no comments, tens of single digit variables, and the control flow is ridiculously hard to follow. In many places the same code is simply copy-pasted rather than being encapsulated, which is why there are two changes to the source code. In other words: if you have another zip implementation, I suggest you go with that :). --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
claunia added the pull-request label 2026-01-29 22:17:51 +00:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
duplicate
enhancement
feedback requested
not bug
pull-request
Mirrored from GitHub Pull Request
 question
up for grabs
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
claunia
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/sharpcompress#846
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?