zipfile should reject inconsistent disk information in EOCDR

Bug report

Bug description:

zipfile is explicitly documented as not handling multipart (i.e. multi-disk) ZIPs.

However, zipfile also does not check the EOCDR's state for consistency with that invariant.

Two fields are relevant (offsets are relative to the start of the EOCDR):

• "number of this disk" (offset 4, size 2)
• "number of the disk with the start of the central directory" (offset 6, size 2)

In zipfile's model, both of these should always be 0, since there's exactly one "disk."

However, at the moment, zipfile appears to silently ignore these fields and allows a parse even when they're incoherent or inconsistent with each other. For example:

import io
import struct
import zipfile

archive = io.BytesIO()
with zipfile.ZipFile(archive, "w") as zipf:
    zipf.writestr("entry.txt", b"payload")
data = bytearray(archive.getvalue())
eocd = data.rfind(zipfile.stringEndArchive)
struct.pack_into("<H", data, eocd + 4, 1)
with zipfile.ZipFile(io.BytesIO(data)) as zipf:
    print(zipf.namelist())

This exposes ['entry.txt'], whereas other parsers (Rust's zip and async_zip, Info-ZIP, and 7-ZIP) reject the ZIP as malformed.

CPython versions tested on:

CPython main branch

Operating systems tested on:

No response

Linked PRs

• gh-155814

Commencez par reproduire l’exemple BytesIO de l’issue et suivre l’analyse EOCDR de zipfile, en vous concentrant sur les deux champs de numéro de disque aux offsets 4 et 6. Le travail est considéré comme terminé lorsque les archives malformées contenant des informations de disque non nulles ou incohérentes sont rejetées au lieu d’être analysées avec succès ; l’issue renvoie à la PR gh-155814 pour les travaux en cours.