Skip to content
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

Open
bothzoli opened this issue Dec 4, 2024 · 2 comments
Open

Strong naming assembly #192

bothzoli opened this issue Dec 4, 2024 · 2 comments

Comments

@bothzoli
Copy link

bothzoli commented Dec 4, 2024

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!

@AArnott
Copy link

AArnott commented Feb 13, 2025

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. :)

@bothzoli
Copy link
Author

I just created a proof-of-concept PR to demonstrate how easy it would be to set this up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants