-
Notifications
You must be signed in to change notification settings - Fork 167
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Strong naming assembly #192
Comments
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. :) |
I just created a proof-of-concept PR to demonstrate how easy it would be to set this up. |
Hi @mcintyre321,
This is related to #38, #119 and #122.
I wonder if you've changed your opinion about providing a strong named version of
OneOf
(like Dapper.StrongName or CSharpFunctionalExtensions.StrongName).I'd be happy to help with that if you'd like me to as I'm considering using this package in a project that needs strong named assemblies.
If you'd prefer not to, that's also cool, I'd most likely either fork
OneOf
, create a similar package myself based onOneOf
or just simply copy the code that I need from it.Cheers!
The text was updated successfully, but these errors were encountered: