Sign the assemblies that we publish

[mwadams]

We have had a request from @gregsdennis to sign the assemblies, so that we can support upstream users who have signed assemblies, without producing a warning.

[idg10]

Could you or @gregsdennis clarify whether this is a request to:

• make these strongly-named assemblies with a corresponding signature (i.e., nothing certificate based, just the old-school strong name signature that we're now all encouraged not to rely on)
• embed an authenticode code signature in the actual DLLs themselves
• generate a signature for the NuGet package

Or Some combination of the above?

I'm not clear on what exactly is blocking upstream users, so I'm not sure exactly what will be required to support them properly.

[gregsdennis]

The first one. I've been signing my packages forever because it was requested of me long ago. And the system still complains when you reference an unsigned package from a signed one.

I am curious why it's discouraged now, though.

[mwadams]

https://learn.microsoft.com/en-us/dotnet/standard/assembly/strong-named#why-strong-name-your-assemblies

Specifically

For .NET Core and .NET 5+, strong-named assemblies do not provide material benefits. The runtime never validates the strong-name signature, nor does it use the strong-name for assembly binding.

If you are an open-source developer and you want the identity benefits of a strong-named assembly for better compatibility with .NET Framework, consider checking in the private key associated with an assembly to your source control system.

Personally, I suspect that most users who are operating in a strong-named environment are unaware that there are no benefits in .NET Core and that there are no security benefits in .NET Framework.

Forcing people to acknowledge and disable the strong-name warnings strikes me as a good way to educate people about the fact that they probably don't want to strong-name sign their assemblies in this way.

[gregsdennis]

Fair enough, but the signing checks do still exist in Framework, and we're publishing Standard-compatible code to be used in Framework.

Moreover, there are users (specifically in Framework) who require signed packages through company policies. We can try to educate them, but until they change those policies, they won't use our packages if they're not signed.

As it stands, I'm still signing my packages. I have committed the signing file, though.