-
Notifications
You must be signed in to change notification settings - Fork 976
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
In ZipOutputStream.PutNextEntry, account for AES overhead when calculating compressed entry size #460
Conversation
211330f
to
96603b3
Compare
Updated to move some of the duplicated overhead size calculation logic to an 'EncryptionOverheadSize' property on ZipEntry, and also changed ZipEntry.LocalHeaderRequiresZip64 to use that instead of always using the ZipCrypto constant. |
A small observation about the length calculation logic ZipOutputStream.CloseEntry that I noticed when looking at this: When calculating the compressed size of the entry, it does
but then after that it does
and inside
So it looks like it counts the crypto overhead twice. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems to do the right things, but might be shortened?
ok, too much copy/pasting, will have a look over the weekend. |
96603b3
to
99cb356
Compare
…ating compressed entry size
99cb356
to
8d876e3
Compare
updated |
Found when looking at #454:
The code at:
SharpZipLib/src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs
Line 330 in f36ca37
for writing entries when the header information is known tries to take account of the crypto header overhead, but only does so for ZipCrypto encrypted entries - it uses the wrong values for AES entries.
Also, the code for building the Zip64 extra data at:
SharpZipLib/src/ICSharpCode.SharpZipLib/Zip/ZipOutputStream.cs
Line 375 in f36ca37
doesn't take account of that overhead at all, which seems to also produce incorrect archives.
Thebecomes a bit more true with the simple change, as it duplicates a bit more logic that could perhaps do with being shared.PR adds a set of test cases for different encryption/compression methds, with and without zip64, but only for 0 byte entries - something with populated entries whose size and crc are known upfront might be useful seperately.
I certify that I own, and have sufficient rights to contribute, all source code and related material intended to be compiled or integrated with the source code for the SharpZipLib open source product (the "Contribution"). My Contribution is licensed under the MIT License.