Skip to content

Conversation

@piksel
Copy link
Member

@piksel piksel commented Dec 19, 2020

This skips AES calculation for AES encrypted entries to align with AE-2.

Fixes #552

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.

if (testing && testData && this[entryIndex].IsFile)
{
// Don't check CRC for AES encrypted archives
var checkCRC = this[entryIndex].AESKeySize == 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should whether the CRC is checked on read depend on the whether the entry is AE-1 or AE-2, rather than just being sklpped for all AES entries? (e.g. dependant the _aesVer value in ZipEntry)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It could, but then it would fail on archives that would otherwise be perfectly OK. The reason for it being dropped in AE-2 is that it's not necessary in AE-1.
I don't think TestArchive should fail because the file is technically out of spec, even though it's fully readable. This method is used in our own tests as well, but it's "main" purpose is for the consumer to verify that an archive is valid before attempting extraction etc.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

AES encrypted Zips not matching specification

3 participants