Zip unix file permissions are not restored properly when importing nuget package

[awakecoding]

NuGet Product Used

dotnet.exe

Product Version

8.0.203

Worked before?

it's been broken forever as far as I know

Impact

It's more difficult to complete my work

Repro Steps & Context

Nuget does not properly restore the unix file permissions encoded in the .nupkg zip file, which is particularly annoying when packaging executables to be imported into a .NET application for redistribution. I maintain an OpenSSH distribution for which the 'ssh' executable is included in the Devolutions.OpenSSH.Client nuget package we import into Remote Desktop Manager (.NET application) for Windows, macOS and Linux. Since nuget does not retain the unix file permissions properly when imported, we have to manually fix the file permissions locally with chmod commands. In the past, we've wasted a lot of time writing special .targets files that would call chmod commands, now we've switched to doing it in the CI environment. Either way, it's very annoying that nuget is currently not capable of just packaging files that will properly retain the correct unix file permissions when imported, forcing us to resort to less-than-desirable solutions.

To reproduce this issue, simply import Devolutions.OpenSSH.Client versions 9.5.0.1 from nuget.org, and look at the imported file permissions on the 'ssh' executables in the local nuget package cache:

Now download the raw .nupkg file, change the extension to .zip and unzip it with the 'unzip' command on Linux, or even inspect its contents with 7-Zip or NanaZip on Windows without extracting it. All other zip tools I've tried correctly decode the zip file permissions on the 'ssh' executables contained within the .nupkg file, and restore them properly when unzipping on a non-Windows (Linux, macOS) file system.

There are various related issues (main issue) but they're not clearly scoped to zip file permissions when importing packages, and reading them, one could think it's an issue that's been fixed years ago when it clearly hasn't been fixed, and probably has never worked properly. Following a discussion on twitter regarding this problem, please do not mark this one as duplicate, because it isn't. Let's scope this problem correctly this time, and get it fixed.

While researching the root cause of the problem, this pull request seemed relevant, along with parts of NuGetExtractionFileIO.cs here and here.

Additionally, the problem has been discussed on twitter here as well, with additional context.

Verbose Logs

No response