gh-72680: Fix false positives when using zipfile.is_zipfile()

[jjolly]

Fix zipfile validation issue by ... providing more validation!

Originally, zipfile.is_zipfile() only checked the End Central Directory
signature. If the signature could be found in the last 64k of the file,
success! This produced false positives on any file with 'PK\x05\x06' in the
last 64k of the file - including PDFs and PNGs.

This is now corrected by actually validating the Central Directory location
and size based on the information provided by the End Central Directory
along with verifying the Central Directory signature of the first entry.

This should be sufficient for the vast number of zipfiles, but more could be
done to absolutely validate the zipfile content - such as validating all
local file headers and Central Directory entries.

https://bugs.python.org/issue28494

• Issue: is_zipfile false positives #72680

[gpshead]

Can you expand the unit testing for is_zipfile? is_zipfile should effectively suggest that zipfile.ZipFile will be able to read the archive and in particular a False return value should always mean that zipfile.ZipFile would fail to read it (ie: we don't want is_zipfile to fail something but be a file we could've read). We don't have much more than very basic coverage of this in the test_zipfile.py and test_zipfile64.py today.

It would not be unreasonable to assertTrue and assertFalse as appropriate the result of is_zipfile() on any test .zip file that a test is using (writing, reading, or both), valid or invalid, and any zip file contents being opened for read.

[jjolly]

Can you expand the unit testing for is_zipfile? is_zipfile should effectively suggest that zipfile.ZipFile will be able to read the archive and in particular a False return value should always mean that zipfile.ZipFile would fail to read it (ie: we don't want is_zipfile to fail something but be a file we could've read). We don't have much more than very basic coverage of this in the test_zipfile.py and test_zipfile64.py today.

I've added a PNG file that would succeed under the old algorithm, but fails correctly with the new algorithm. Perhaps the PNG is overkill, but it's proof that a valid format for another file should fail as a ZIP archive.

It would not be unreasonable to assertTrue and assertFalse as appropriate the result of is_zipfile() on any test .zip file that a test is using (writing, reading, or both), valid or invalid, and any zip file contents being opened for read.

I've added a few checks throughout the test_zipfile.py script. If you see others you would like to check, let me know and I can add them.

[gpshead]

FYI - This PR as is causes zipfile.is_zipfile to start rejecting some valid zipfiles that zipfile.ZipFile() happily opens and properly processes. I'm looking into why and how to best update the test suite to reveal this...

[github-actions]

This PR is stale because it has been open for 30 days with no activity.

[arhadthedev]

I'm looking into why and how to best update the test suite to reveal this...

@gpshead ping

[github-actions]

This PR is stale because it has been open for 30 days with no activity.