.NET Core tar.gz downloads are unsigned

[sdmaclea]

The tar.gz downloads on the .NET releases website are unsigned.

This causes usage of these to trigger malicious software warnings on some OSs.

On Apple Silicon, these binaries get silently killed by the kernel unless System Integrity Protection is disable and developer mode is enabled.

• The ideal fix would be to fix arcade to properly sign tar.gz binaries. (Or rebuild the tar.gz from signed binaries in the packages)
• If this can't be fixed a much less desirable solution would be to remove them from the website. Several people have indicated this would be undesirable.

See discussion beginning here dotnet/runtime#44897 (comment)

/cc @richlander

[mmitche]

@sdmaclea Do we have an exact set of binaries that need to be signed within those archives?

I think this is more easily fixed in 6 than 5, but should be possible in both. The post build signing in 6 means all the signing is running on a Windows machine. For 5.0, it may mean finding an appropriate spot to put in-build signing for mac (this may already exist though).

[sdmaclea]

I personally do not have an exact list. @hoyosjs may have an idea how to get this.

For Apple Silicon, the native binaries need to be signed. This would include dotnet, createdump, and all the dylib shared libraries.

The apphost template(s) are more unclear. Ideally in my mind the template should be signed and we would remove the signature when publishing it as a user's exe. @vitek-karas would know more here.

I actually think we should be signing IL/crossgen binaries too.

For other platforms, it is likely similar, but with different problems if this isn't fixed. Azure might refuse to run the unsigned binaries for instance.

[sdmaclea]

In case I answered the wrong question....

I also do not know exactly which platforms and releases were affected. I only looked at the .NET 5 macOS x64 tar.gz release. I would guess this would affect any release using the new signing mechanisms.

[hoyosjs]

Will check this later when I have an access to a macOS device.

[mmitche]

I don't believe we sign any *nix or OSX executable binaries today within the archives. Within nix zip files, the MSIL binaries are probably signed in 6.0 (based on post-build signing) and may be somewhat signed in 5.0 (based on where package signing happens).

[blowdart]

The apphost template(s) are more unclear. Ideally in my mind the template should be signed and we would remove the signature when publishing it as a user's exe. @vitek-karas would know more here.

We've been through this before on windows. The app.exe on windows that is used to bundle into app distribution is deliberately not signed, because it would have a Microsoft signature, and thus would look like Microsoft code due to the signature, rather than user code. That must also be the approach on Apple.

[hoyosjs]

hmm, I'm surprised we don't for macOS and variants. It will definitely be needed if SIP is enabled. At least for the dotnet host and such. AppHost and SuperHost can't be signed given Barry's comment until they've been fully rewritten to point to the end-users application logic. In Azure Environments you do have a signing requirement, depending on the environment, and it does require 400's, but the enforcement is only on Windows AFAIK.

[mmitche]

hmm, I'm surprised we don't for macOS and variants. It will definitely be needed if SIP is enabled. At least for the dotnet host and such. AppHost and SuperHost can't be signed given Barry's comment until they've been fully rewritten to point to the end-users application logic. In Azure Environments you do have a signing requirement, depending on the environment, and it does require 400's, but the enforcement is only on Windows AFAIK.

Wouldn't that mean that Azure is responsible for signing those binaries if they are distributing them?

[hoyosjs]

Those particular ones, yes (the hosts that were mentioned). But not the framework and the generic host. Those don't get modified once they leave our build pipeline. This will be particularly relevant for macOS on M1, just because of the level of protections required. Should this be in this repo? It feels like signtool and the release pipeline are the ones that require this modification. (I don't know why we are shipping unsigned finalized binaries through VS download links. That feels like something that would go against SDL requirements. Not sure if the requirements don't yet cover Apple codesign).

[sdmaclea]

Should this be in this repo?

I put it here because it affects our downloads website. If nothing else the website needs this as a nexternal issue to track getting this fixed.

I don't know why we are shipping unsigned finalized binaries through VS download links.

Yes this is ugly. @richlander asked to get this fixed, so I opened this issue.

It feels like if we are releasing this binaries, we should be signing them. The installer ones for macOS are signed, but the tar.gz ones are not. We should be signing the release binaries for all platforms IMHO.

[k15tfu]

BTW, I think that it causes dotnet/runtime#38306.

[richlander]

I just installed the latest .NET 8 SDK stable build for macOS Arm64. It works.

https://dotnet.microsoft.com/download/dotnet/8.0

I also did this:

rich@Richs-Air dotnet-sdk-8.0.101-osx-arm64 % codesign -d -r- dotnet 
Executable=/Users/rich/Downloads/dotnet-sdk-8.0.101-osx-arm64/dotnet
designated => identifier "dotnet-555549442026c5b394df38ec90536cf87776be3e" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = UBF8T346G9

I am not an expert on what that all means, but it looks impressive. Based on the empirical observation, I'm going to close this issue.