The attached file produces the following stacktrace when opened via `zipfile.ZipFile`, on Python 3.7.5rc1:

```
$ cat ziprepro.py 
import zipfile
import sys

zipfile.ZipFile(sys.argv[1])
```

```
$ python3 ziprepro.py crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62
Traceback (most recent call last):
  File "ziprepro.py", line 4, in <module>
    zipfile.ZipFile(sys.argv[1])
  File "/usr/lib/python3.7/zipfile.py", line 1225, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.7/zipfile.py", line 1310, in _RealGetContents
    fp.seek(self.start_dir, 0)
ValueError: cannot fit 'int' into an offset-sized integer
```

The ValueError exception isn't documented as a possible exception when using zipfile.ZipFile ( https://docs.python.org/3/library/tarfile.html ).

It's unlikely that anyone will download a binary from bpo and open it. Can you help us reproduce the issue without that?

First question is whether you can reproduce this on a version of python that is still in maintenance - 3.9 or higher?

Yes, I can reproduce it:

```
$ python3 --version
Python 3.9.9

$ python3.9 ziprepo.py ./crash-4da08e9ababa495ac51ecad588fd61081a66b5bb6e7a0e791f44907fa274ec62 
Traceback (most recent call last):
  File "/home/jvoisin/Downloads/ziprepo.py", line 4, in <module>
    zipfile.ZipFile(sys.argv[1])
  File "/usr/lib/python3.9/zipfile.py", line 1257, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.9/zipfile.py", line 1342, in _RealGetContents
    fp.seek(self.start_dir, 0)
ValueError: cannot fit 'int' into an offset-sized integer
$
```

> It's unlikely that anyone will download a binary from bpo and open it. Can you help us reproduce the issue without that?

The *binary* is a corrupted zip file to open with `zipfile.ZipFile()`, it can't be executed on its own.

It's easy enough to convert the exception type (see patch), but I don't know how to write a unit test for this.

Try to create a normal ZIP file (it can be empty), then try to set some byte to FF (or a pair of bytes to FFFF, or 4 consequent bytes to FFFFFFFF, until you get the exactly same error). Then you can just add the binary dump of that file in tests.

One way of doing this is by making the central directory offset negative by first taking the zip file containing just an EOCD record and then listing the total size of the central directory records as positive.

```
Python 3.11.0a4+ (heads/bpo-39064:eb1935dacf, Apr  3 2022, 19:09:53) [GCC 11.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import zipfile
>>> import io
>>> b = [80, 75, 5, 6, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]
>>> b[12] = 1
>>> f = io.BytesIO(bytes(b))
>>> zipfile.ZipFile(f)
Traceback (most recent call last):
  File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1370, in _RealGetContents
    fp.seek(self.start_dir, 0)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^
ValueError: negative seek value -1

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1284, in __init__
    self._RealGetContents()
    ^^^^^^^^^^^^^^^^^^^^^^^
  File "/run/media/sam/OS/Git/cpython/Lib/zipfile.py", line 1372, in _RealGetContents
    raise BadZipFile("Bad offset for central directory")
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
zipfile.BadZipFile: Bad offset for central directory
>>> 
```

Sam, can you put that in a PR please?

Yes, of course.