You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please strong name your assemblies. It's easy, and opens your code up for use by other libraries and apps that already strong name their assemblies on .NET Framework.
Following are some points that refute some misinformation out there that often discourages developers from strong naming their libraries:
Strong naming isn't about security. The .NET team has said as much officially. In their official guidance, they tout the merit of strong naming as avoiding assembly naming conflicts:
Strong naming refers to signing an assembly with a key, producing a strong-named assembly. When an assembly is strong-named, it creates a unique identity based on the name and assembly version number, and it can help prevent assembly conflicts.
They further state:
✔️ CONSIDER adding the strong naming key to your source control system.
A publicly available key lets developers modify and recompile your library source code with the same key.
So you see, strong naming is not for verifying the authenticity of the publisher. Therefore, disclosing the .snk publicly in an OSS repo is perfectly fine. You lose nothing as an OSS non-strong-named library by adding a strong name (except binary compatibility with previous versions of your library when a user is running on .NET Framework). You didn't have publisher security before, and you don't after. But you gain a whole set of .NET Framework customers who already strong name their assemblies and are technically prevented from referencing assemblies that are not strong named.
Many OSS repos (including all of my own) check in the .snk for their own use and to maintain the spirit of OSS, which is that anyone can modify and rebuild an assembly and use it in place of the original. Strong naming and hiding the private key would violate that, but Strong naming and disclosing the private key maintains that.
Please strong name the assembly. :)
The text was updated successfully, but these errors were encountered:
Please strong name your assemblies. It's easy, and opens your code up for use by other libraries and apps that already strong name their assemblies on .NET Framework.
Following are some points that refute some misinformation out there that often discourages developers from strong naming their libraries:
Strong naming isn't about security. The .NET team has said as much officially. In their official guidance, they tout the merit of strong naming as avoiding assembly naming conflicts:
They further state:
And...
So you see, strong naming is not for verifying the authenticity of the publisher. Therefore, disclosing the .snk publicly in an OSS repo is perfectly fine. You lose nothing as an OSS non-strong-named library by adding a strong name (except binary compatibility with previous versions of your library when a user is running on .NET Framework). You didn't have publisher security before, and you don't after. But you gain a whole set of .NET Framework customers who already strong name their assemblies and are technically prevented from referencing assemblies that are not strong named.
Many OSS repos (including all of my own) check in the .snk for their own use and to maintain the spirit of OSS, which is that anyone can modify and rebuild an assembly and use it in place of the original. Strong naming and hiding the private key would violate that, but Strong naming and disclosing the private key maintains that.
Please strong name the assembly. :)
The text was updated successfully, but these errors were encountered: