TarReader corrupts entry names when reading Mac-generated tarballs containing symlinks with long targets

[MichaelSimons]

Description

System.Formats.Tar.TarReader drops the directory prefix from entry names when reading tarballs generated by macOS bsdtar that contain symbolic links with targets exceeding 100 bytes. For example, an entry with path ./sdk/tools/net11.0/any/SomeAssembly.dll is read back as tools/net11.0/any/SomeAssembly.dll — the ./sdk/ prefix is lost.

Repro

Given a Mac-generated signed SDK tarball (e.g., dotnet-sdk-11.0.100-preview.3.26151.101-osx-x64.tar.gz):

using System.Formats.Tar;
using System.IO.Compression;
using var reader = new TarReader(new GZipStream(File.OpenRead(args[0]), CompressionMode.Decompress));
while (reader.GetNextEntry() is TarEntry entry)
{
    if (!entry.Name.StartsWith("./"))
        Console.WriteLine($"BROKEN: Name={entry.Name}  Type={entry.EntryType}  LinkName={entry.LinkName}");
}

Expected: All entry names preserve their original path (e.g., ./sdk/tools/net11.0/any/...).

Actual: Certain symlink entries lose their leading directory components:
BROKEN: Name=tools/net11.0/any/Microsoft.CodeAnalysis.Workspaces.MSBuild.BuildHost.dll Type=SymbolicLink LinkName=../../../../../dotnet-format/BuildHost-netcore/Microsoft.CodeAnalysis.Workspaces.MSBuild.BuildHost.dll
BROKEN: Name=tools/net11.0/any/BuildHost-netcore/Microsoft.CodeAnalysis.Workspaces.MSBuild.BuildHost.dll Type=SymbolicLink LinkName=../../../../../../dotnet-format/BuildHost-netcore/Microsoft.CodeAnalysis.Workspaces.MSBuild.BuildHost.dll
...

Only symlinks whose link target path exceeds 100 bytes are affected. Non-symlink entries and symlinks with shorter targets read correctly.

Impact

Round-tripping a Mac tarball through TarReader/TarWriter produces a corrupted archive where affected entries are extracted to the wrong paths. This breaks scenarios like SDK installer layout generation that rely on reading and rewriting Mac tarballs. Linux-generated tarballs are not affected because GNU tar uses a different metadata format for long link targets.

[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.

[MichaelSimons]

Root Cause Analysis (From AI)

The bug is in TarHeader.Read.cs in the TryReadAttributes method.

When TarReader encounters a PAX extended attributes entry (type x), it reads the actual entry that follows by calling TryGetNextHeader with initialFormat = TarEntryFormat.Pax. This pre-sets _format = Pax on the header, which causes the reader to skip ReadUstarAttributes() — the method responsible for reading the USTAR prefix field and combining it with name to form the full path:

// TarHeader.Read.cs - TryReadAttributes
if (header._format == TarEntryFormat.Ustar)
{
    header.ReadUstarAttributes(buffer);  // reads prefix, sets _name = $"{_prefix}/{_name}"
}
else if (header._format == TarEntryFormat.Gnu)
{
    header.ReadGnuAttributes(buffer);
}
// In PAX, there is nothing to read in this section (empty space)

macOS bsdtar writes the actual entry header in USTAR format — the path is split across the prefix (155 bytes) and name (100 bytes) fields. It only emits a PAX extended header for the specific field that overflows, e.g., linkpath when the symlink target exceeds 100 bytes. Crucially, it does not include a path key in the extended attributes when the entry name fits in the USTAR prefix+name fields.

Since the reader skips ReadUstarAttributes, the prefix is never read. And since there's no path key in the extended attributes, ReplaceNormalAttributesWithExtended has nothing to correct it with. The result is a truncated _name containing only the 100-byte name field.

Relevant code paths

• TryProcessExtendedAttributesHeader passes TarEntryFormat.Pax → TarReader.cs L383
• TryReadAttributes skips USTAR prefix for PAX format → TarHeader.Read.cs L80-88
• ReadUstarAttributes combines prefix + name → TarHeader.Read.cs L600-611

Potential fix

When reading a PAX entry, also read the USTAR prefix field from the header buffer and apply it to _name if no path key is present in the extended attributes.

[MichaelSimons]

This is breaking the .NET signing infrastructure. Is it possible to get a fix in for 11.0 preview 3?