Solve symlinks destination by alinpahontu2912 · Pull Request #129281 · dotnet/runtime

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

alinpahontu2912 · 2026-06-11T08:50:51Z

Evaluate symlinks destination properly

dotnet-policy-service · 2026-06-11T08:52:15Z

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

Copilot

Pull request overview

This PR tightens System.Formats.Tar extraction safety by validating that computed extraction destinations (including link destinations) don’t escape the intended destination directory once filesystem symlinks are taken into account, and adds tests intended to cover symlink-based directory traversal scenarios.

Changes:

Add a symlink-aware escape check (FilePathEscapesDirectory) during destination and link path validation in TarEntry.
Extend extraction validation to reject entries whose resolved destinations would traverse outside the destination directory.
Add new extraction tests covering symlink traversal attempts (including chained symlinks).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

File	Description
src/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs	Adds symlink-aware escape validation for extraction destination paths and link destinations.
src/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs	Adds new tests intended to validate rejection of symlink-based directory traversal during extraction.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

(holding for offline feedback)

GrabYourPitchforks

This looks like it's providing a guarantee we do not intend to provide.

There needs to be a prominent code comment to echo the Remarks section at https://learn.microsoft.com/en-us/dotnet/api/system.formats.tar.tarfile.extracttodirectory:

This is only intended to guard against the case where both:

a symlink tries to break out of the destination folder; and
the symlink is introduced by an entry within the archive.

No specific defenses are intended for the case where a symlink already exists in the destination folder, as the destination folder is assumed trustworthy. (See also: https://github.com/dotnet/core/blob/main/Documentation/security-foundations/baseline-security-assumptions.md#23-the-command-line-is-trusted-as-a-control-plane-mechanism)

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.

GrabYourPitchforks

The comment as proposed on line 418 is still misleading.

The comment needs to clearly state that we intend to defend this ONLY WHEN a directory-escaping symlink is introduced by the archive itself. We do not intend to defend other scenarios, including when preexisting symlinks on disk link outside the destination directory.

Note: Nothing stops you from blocking preexisting-symlink scenarios if you decide you no longer want to follow them. For example, maybe this is the easiest way to also block the "hostile symlink within an archive" scenario. (Though currently your public docs say you follow existing symlinks, so this would be a breaking change.)

The crux of my comment is that we absolutely cannot have any comment or behavior which can be misinterpreted as "we intend to defend against hostile symlinks already on disk." If we want to make a behavioral change to how we interpret preexisting symlinks, that's totally fine, but a reader or future maintainer must be able to easily understand that we're not trying to offer a defense specifically against existing hostile symlinks.

Copilot

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

GrabYourPitchforks

My concerns are addressed. Thanks. :)

Removing block.

Evaluate symlinks destination properly

Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a

* Extract release archives with managed APIs to prevent tar-slip The github-release update path extracted downloaded assets by shelling out to `tar -xzf`, which honors entries containing `../` and can write files outside the extraction directory (tar-slip / path traversal) from an attacker-controlled release asset. Replace the external `tar` call with managed extraction via System.Formats.Tar.TarFile over a GZipStream (and ZipFile on Windows), both of which reject entries that escape the destination directory. Factored into a testable TryExtractReleaseArchive helper. Adds tests covering rejection of a tar-slip entry and successful extraction of a legitimate tarball. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a * Harden tar extraction against symlink escape and untrusted runtimes Adversarial review noted that TarFile.ExtractToDirectory does not reject chained-symlink traversal on all supported runtimes (the physical symlink-containment fix, dotnet/runtime#129281, is not present in the preview this repo currently builds against). A malicious tar could create a symlink to an outside directory then write a file through it, escaping the extraction directory before payload validation runs. Walk the tar entries explicitly instead: reject any link/device/fifo entry (a single-file tool payload never contains them), and independently contain each entry's resolved path within the extraction directory rather than trusting the runtime. Windows keeps ZipFile.ExtractToDirectory. Adds tests for symlink-entry rejection and the chained-symlink escape. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 93b4a21a-2d53-4208-9078-2643c540666a --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>

solve symlinks before extraction
1bb7be1

alinpahontu2912 requested review from a team and Copilot June 11, 2026 08:50

Copilotstarted reviewing on behalf of alinpahontu2912 June 11, 2026 08:51 View session

github-actionsBot added the area-System.Formats.Tar label Jun 11, 2026

dotnet-policy-serviceBot assigned alinpahontu2912 Jun 11, 2026

CopilotAI reviewed Jun 11, 2026
View reviewed changes

rzikm approved these changes Jun 11, 2026
View reviewed changes

am11 reviewed Jun 11, 2026
View reviewed changes

Comment threadsrc/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs

am11 reviewed Jun 11, 2026
View reviewed changes

Comment threadsrc/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs

Separate logical and physical path handling
4f88961

build-analysisBot mentioned this pull request Jun 11, 2026
System.Runtime.Tests.ControlledExecutionTests failing with fatal error #129270
Closed

CopilotAI review requested due to automatic review settings June 18, 2026 07:42

alinpahontu2912 force-pushed the symlink_resolution branch from 4f88961 to ef504a5Compare June 18, 2026 07:42

Copilotstarted reviewing on behalf of alinpahontu2912 June 18, 2026 07:43 View session

alinpahontu2912 requested a review from rzikm June 18, 2026 07:45

CopilotAI reviewed Jun 18, 2026
View reviewed changes

Comment threadsrc/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs Outdated
Comment threadsrc/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs
Comment threadsrc/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs

build-analysisBot mentioned this pull request Jun 18, 2026
The Operation will be canceled. The next steps may not contain expected logs. dotnet/dnceng#3008
Open
3 tasks

alinpahontu2912 enabled auto-merge (squash) June 23, 2026 07:02

alinpahontu2912 requested a review from a teamJune 24, 2026 05:46

alinpahontu2912 added 2 commits June 24, 2026 13:18

solve symlinks before extraction
d2ffbdc

Separate logical and physical path handling
a1b2aab

alinpahontu2912 force-pushed the symlink_resolution branch from ef504a5 to a1b2aabCompare June 24, 2026 10:18

GrabYourPitchforks requested changes Jun 24, 2026
View reviewed changes

CopilotAI mentioned this pull request Jun 24, 2026
Fix flaky SendAsync_Success_ConnectionSetupActivityGraphRecorded test (Http1.1 + Http2) #129822
Closed

add comment explaining behaviour
8c91e3b

CopilotAI review requested due to automatic review settings June 26, 2026 09:16

Copilotstarted reviewing on behalf of alinpahontu2912 June 26, 2026 09:17 View session

CopilotAI reviewed Jun 26, 2026
View reviewed changes

build-analysisBot mentioned this pull request Jun 26, 2026
TestNativeDigits fails for ur-IN on Apple platforms (xunit v3 exposed previously non-running test) #125933
Closed

alinpahontu2912 added 2 commits June 29, 2026 12:49

address comments
5f6acea

fix conflicts
bf5902c

GrabYourPitchforks previously requested changes Jun 29, 2026
View reviewed changes

update explanation
32f1c2b

CopilotAI review requested due to automatic review settings July 1, 2026 07:13

Copilotstarted reviewing on behalf of alinpahontu2912 July 1, 2026 07:14 View session

CopilotAI reviewed Jul 1, 2026
View reviewed changes

Comment threadsrc/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs
Comment threadsrc/libraries/System.Formats.Tar/src/System/Formats/Tar/TarEntry.cs
Comment threadsrc/libraries/System.Formats.Tar/tests/TarFile/TarFile.ExtractToDirectory.File.Tests.cs

This was referenced Jul 1, 2026
slow macOS - "##[error]The job running on agent Azure Pipelines 9 ran longer than the maximum time of 60 minutes." dotnet/dnceng#1883
Open
browser-wasm linux Release LibraryTests queues timing out #117974
Open

alinpahontu2912 requested a review from GrabYourPitchforks July 2, 2026 12:06

GrabYourPitchforks reviewed Jul 2, 2026
View reviewed changes

Merge branch 'main' into symlink_resolution
98945b3

build-analysisBot mentioned this pull request Jul 2, 2026
[ci-scan] Test failure: System.Threading.Tests.MutexTests.CrossProcess_NamedMutex_ConcurrentCreateOrOpen #130125
Closed

rzikm approved these changes Jul 3, 2026
View reviewed changes

alinpahontu2912 merged commit 710da3b into dotnet:mainJul 3, 2026
86 of 88 checks passed

dotnet-maestroBot mentioned this pull request Jul 4, 2026
[main] Source code updates from dotnet/runtime dotnet/dotnet#7544
Merged

dotnet-milestone-botBot added this to the 11.0-preview7 milestone Jul 4, 2026

LoopedBard3 mentioned this pull request Jul 7, 2026
[Perf] Windows/x64: 4 Regressions on 7/3/2026 10:18:16 AM +00:00 #130309
Open

eiriktsarpalis pushed a commit that referenced this pull request Jul 15, 2026
Solve symlinks destination (#129281)
3effb2e
Evaluate symlinks destination properly

github-actionsBot locked and limited conversation to collaborators Aug 4, 2026