Strong naming assembly
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 on OneOf or just simply copy the code that I need from it.
Cheers!
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.
And...
When the identity of the publisher of the code is desired, Authenticode and NuGet Package Signing are recommended.
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.
The lack of a strong name version of this library created a problem for TensorFlow.NET. https://github.com/SciSharp/TensorFlow.NET/issues/1296
Please strong name this assembly.