TarInputStream.GetNextEntry hangs on corrupt archive

Steps to reproduce

var httpClient = new HttpClient();
var stream = await httpClient.GetStreamAsync("https://files.pythonhosted.org/packages/04/b5/fea02ac9306b5d56a5019133f4edda6c9e3cfbd1b5ce663158486ba77eea/diffpy.srfit-1.3.tar.gz");
var gzipStream = new GZipInputStream(stream);
var tarStream = new TarInputStream(gzipStream, Encoding.ASCII);

while (tarStream.CanRead)
{
  var entry = tarStream.GetNextEntry();

  if (entry == null)
  {
    break;
  }
}

tarStream.Close();
gzipStream.Close();

Expected behavior

Exception should be thrown if archive cannot be processed.

Actual behavior

GetNextEntry() call hangs.

Version of SharpZipLib

1.3.3

Obtained from (only keep the relevant lines)

• Package installed using NuGet

Other notes

Archive is an older python package hosted on PyPi.

Inspecting archive with 7zip shows “Unexpected end of data” for many files.

Also tried fully reading http response stream into byte array and reading from memory stream, same problem.

[piksel]

@mikaeleiman Yeah, then it probably is #788. It’s fixed in master and should be released with 1.4.1 pretty soon. The example file you provided extracts using master as well:

❯ dotnet run -- -xvfz ~/Downloads/example-762.tar.gz
drwx------ user/None        0 2022-11-04 14:31:27 ./debuglog/
-rw------- user/None      476 2022-11-04 14:31:27 ./debuglog/2178.txt
-rw------- user/None     1434 2022-11-04 14:31:27 ./debuglog/2423.txt
-rw------- user/None    37932 2022-11-04 14:31:27 ./debuglog/3966.txt
-rw------- user/None  1127093 2022-11-04 14:31:27 ./debuglog/4324.txt
-rw------- user/None   371028 2022-11-04 14:31:27 ./debuglog/4330.txt
-rw------- user/None   362221 2022-11-04 14:31:27 ./debuglog/4335.txt
-rw------- user/None   360946 2022-11-04 14:31:27 ./debuglog/4341.txt
-rw------- user/None  1286788 2022-11-04 14:31:27 ./debuglog/6000.txt
-rw------- user/None    72234 2022-11-04 14:31:27 ./statistics.txt

[mikaeleiman]

Example file:

example-762.tar.gz

I looked into our code, and it seems that SharpZipLib 1.3.3 handles the file, but 1.4.0 does not. Not sure why we bumped to 1.4.0, but I suspect it was for the dotnet6 support. Seems like 1.3.3 is working fine for our purposes, though.