System.Formats.Tar null-terminated strings not trimmed correctly

[bruce965]

Description

The TarHelpers.GetTrimmedUtf8String() is called here to extract strings from Tar headers:

runtime/src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarHeader.Read.cs

Line 387 in 9e5e6aa

name: TarHelpers.GetTrimmedUtf8String(buffer.Slice(FieldLocations.Name, FieldLengths.Name)),

Internally, TarHelpers.GetTrimmedUtf8String() calls TarHelpers.TrimEndingNullsAndSpaces() that, as the name implies, trims trailing '\0' (0x00) and ' ' (0x20) characters.

According to these specs, these fields are null-terminated character strings.

The name, linkname, magic, uname, and gname are null-terminated character strings.

So the correct thing to do would be to keep as many characters as possible, and stop at the null-terminator character.

Not following this practice causes issues with this tar which contains extra bytes after the null-terminator.

Here's a hex-dump of the header for one of the entries:

.NET interprets this name as "python/bin/idle3.13\0dle3.13" which becomes "python/bin/idle3.13_dle3.13" once extracted. The correct name would be "python/bin/idle3.13".

Reproduction Steps

Download cpython-3.13.5+20250702-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz and place it in the appropriate directory.

Extract it with the following code:

using Stream fileStream = File.OpenRead(@"cpython-3.13.5+20250702-x86_64-unknown-linux-gnu-install_only_stripped.tar.gz");

Directory.CreateDirectory(@"~temp");

using GZipStream tarStream = new(fileStream, CompressionMode.Decompress);

await TarFile.ExtractToDirectoryAsync(tarStream, @"~temp", false);

Expected behavior

File names should respect null-terminated strings, such as in this example:

Actual behavior

File names of the extracted files are incorrect:

Regression?

No response

Known Workarounds

No response

Configuration

.NET 9.0.300

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-formats-tar
See info in area-owners.md if you want to be subscribed.

[ViktorHofer]

cc @tmds

[tmds]

According to these specs, these fields are null-terminated character strings.
So the correct thing to do would be to keep as many characters as possible, and stop at the null-terminator character.

Yes, we should be looking for the first \0 from the start of the field.
Also, I don't think there's a reason to consider space characters.

@bruce965 do you want to contribute a fix?

[bruce965]

@bruce965 do you want to contribute a fix?

My apologies, I don't feel comfortable with the idea.

[tmds]

No worries, I've taken up the issue. If you want to make a contribution some day, the maintainers will assist you.

[ericstj]

What was the reason that the creator of this tar included the bytes after the null? Is it trying to store extra data there, or is it just garbage to be ignored? I ask because we try to be sensitive to round-tripping so I want to understand if we should try to preserve these characters after the null or if they are acceptable to drop. My guess is that they can be dropped and are the result of some tool that "renamed" the file without shifting/zeroing the bytes.

Also - double checking my read - this doesn't appear to be a regression from recent changes, but is a bug that's been present since the introduction of the tar API in 6.0. Do you agree?

[tmds]

Yes, the problem exists since the APIs were introduced. We need to ignore these bytes.