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

Inizia riproducendo l’esempio BytesIO dell’issue e seguendo l’analisi EOCDR di zipfile, concentrandoti sui due campi del numero del disco agli offset 4 e 6. Il lavoro è completato quando gli archivi non validi con informazioni sul disco non nulle o incoerenti vengono rifiutati invece di essere analizzati correttamente; l’issue rimanda alla PR gh-155814 per il lavoro in corso.