Bug report

Bug description:

When an entry uses GNU long name encoding the tarfile module reads in the data blocks for the name and then calls self.fromtarfile() again to get the 'actual' header. This second header is the source of truth for everything except the name which is just garbage data.

The problem is that fromtarfile() eventually calls frombuf() where this logic incorrectly uses the garbage data and overrides the entry type to directory, corrupting the entry.

Because the entry is detected as a directory, the offset is not updated properly and the next call to read a TarInfo entry will usually result in an exception. However, the exception lands up in this block where neither of the if conditions are met, so the exception is silently discarded. tarinfo remains None and the code eventually decides that there are no more entries in the tar file.

I initially ran into this issue due to reports of invalid sdists being generated by maturin.
See: PyO3/maturin#2855

CPython versions tested on:

3.9, 3.10, 3.11, 3.12, 3.13, 3.14

Operating systems tested on:

macOS, Linux

Linked PRs

• gh-141707: Fix tarfile type corruption with GNU long names #143157
• gh-141707: Skip TarInfo DIRTYPE normalization during GNU long name handling #143934
• [3.11] gh-141707: Skip TarInfo DIRTYPE normalization during GNU long name handling #145815
• [3.10] gh-141707: Skip TarInfo DIRTYPE normalization during GNU long name handling #145816
• [3.12] gh-141707: Skip TarInfo DIRTYPE normalization during GNU long name handling #145817
• [3.13] gh-141707: Skip TarInfo DIRTYPE normalization during GNU long name handling #145818
• [3.14] gh-141707: Skip TarInfo DIRTYPE normalization during GNU long name handling #145819