Bug report

Bug description:

Create a ZIP file with duplicate central directory entries pointing to the same local file header (these can be found in the wild, see e.g.https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1068705, this is just an easy way to create one for testing).

>>>importzipfile>>>withzipfile.ZipFile("foo.zip","w")aszf:...info=zipfile.ZipInfo(filename="foo")...zf.writestr(info,"FOO")...zf.filelist.append(info)

Opening the duplicate entry fails if using the name or the later entry ininfolist(), but works using the earlier entry (since the later one is considered to overlap with the earlier one, but the earlier one isn't considered to overlap with another entry or the central directory).

>>>importzipfile>>>zf=zipfile.ZipFile("foo.zip")>>>zf.infolist()[0]<ZipInfofilename='foo'filemode='?rw-------'file_size=3>>>>zf.infolist()[1]<ZipInfofilename='foo'filemode='?rw-------'file_size=3>>>>zf.open("foo")# failszipfile.BadZipFile:Overlappedentries:'foo' (possiblezipbomb)>>>zf.open(zf.infolist()[1])# failszipfile.BadZipFile:Overlappedentries:'foo' (possiblezipbomb)>>>zf.open(zf.infolist()[0])# works fine<zipfile.ZipExtFilename='foo'mode='r'>

If I modifyNameToInfo to contain the earlier entry instead,f.open("foo") works fine. On the one hand these ZIP files are broken. On the other hand, it would be easy to simply not overwrite existing entries inNameToInfo, allowing these files to be opened. And this affects real-world programs trying to open real-world files. So it could be considered a regression caused by#110016). Perhaps a warning would be in order when duplicates are detected; e.g.unzip shows an error but does extract the files.

CPython versions tested on:

3.11, 3.12

Operating systems tested on:

Linux

Linked PRs

• gh-117779: Fix reading duplicated entries in zipfile by name #129254
• [3.13] gh-117779: Fix reading duplicated entries in zipfile by name (GH-129254) #132263
• [3.12] gh-117779: Fix reading duplicated entries in zipfile by name (GH-129254) #132264