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

```
$ cat test.py 
import sys
import tarfile

tarfile.open(sys.argv[1])
$ python3 test.py ./crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82
Traceback (most recent call last):
  File "test.py", line 4, in <module>
    tarfile.open(sys.argv[1])
  File "/usr/lib/python3.7/tarfile.py", line 1573, in open
    return func(name, "r", fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1645, in gzopen
    t = cls.taropen(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1621, in taropen
    return cls(name, mode, fileobj, **kwargs)
  File "/usr/lib/python3.7/tarfile.py", line 1484, in __init__
    self.firstmember = self.next()
  File "/usr/lib/python3.7/tarfile.py", line 2289, in next
    tarinfo = self.tarinfo.fromtarfile(self)
  File "/usr/lib/python3.7/tarfile.py", line 1094, in fromtarfile
    buf = tarfile.fileobj.read(BLOCKSIZE)
  File "/usr/lib/python3.7/gzip.py", line 276, in read
    return self._buffer.read(size)
  File "/usr/lib/python3.7/_compression.py", line 68, in readinto
    data = self.read(len(byte_view))
  File "/usr/lib/python3.7/gzip.py", line 471, in read
    uncompress = self._decompressor.decompress(buf, size)
zlib.error: Error -3 while decompressing data: invalid distances se
```

This file is also an invalid tar file:

$ tar xf crash-c10c9839d987fa0df6912cb4084f43f3ce08ca82 

gzip: stdin: invalid compressed data--format violated
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Sure, but as a user, I would expect a better exception, like ValueError or ReadError, along with an error message, instead of an unexpected zlib exception.

@jvoisin I am able to reproduce the problem when I download your script, but I am having a hard time reproducing it by passing corrupt archives to `tarfile.open`. How exactly was this file corrupted? I am trying to figure out if there are any similar implementation leaks / poor error messages in similar scenarios so I can do my best to patch them all.

You can see the reproduction scripts I am using here to get a better idea of what I have been trying. Be forewarned, they are pretty gnarly!

https://gist.github.com/jdevries3133/acbb5ba2a19093d3bcc214733ef85e5a

The file was created with a fuzzer, like the one described in https://dustri.org/b/fuzzing-python-in-python-and-doing-it-fast.html

New changeset b6fe8572509b77d2002eaddf99d718e9b4835684 by Jack DeVries in branch 'main':
bpo-39039: tarfile raises descriptive exception from zlib.error (GH-27766)
https://github.com/python/cpython/commit/b6fe8572509b77d2002eaddf99d718e9b4835684

New changeset d6b69f21d8ec4af47a9c79f3f50d20be3d0875fc by Łukasz Langa in branch '3.10':
[3.10] bpo-39039: tarfile raises descriptive exception from zlib.error (GH-27766) (GH-28613)
https://github.com/python/cpython/commit/d6b69f21d8ec4af47a9c79f3f50d20be3d0875fc

New changeset 7bff4d396f20451f20977be3ce23a879c6bc3e46 by Łukasz Langa in branch '3.9':
[3.9] bpo-39039: tarfile raises descriptive exception from zlib.error (GH-27766) (GH-28614)
https://github.com/python/cpython/commit/7bff4d396f20451f20977be3ce23a879c6bc3e46

Thanks for the fix, Jack! ✨ 🍰 ✨  

Since the change translated `zlib.error` to `tarfile.ReadError` which already has to be handled by user code, it's strictly decreasing the surface of necessary exception handling. So, treating this as a bug fix, I backported this to 3.9 and 3.10 as well.