问题
I am currently thinking about open-sourcing a project of mine and am in the process of preparing the source code and project structure to be released to the public. Now I got one question: how should I handle the signature key for my assemblies? Should I create a new key for the open-source version and publish it along with the other files to the SVN repository? Should I leave the key out and everyone who wants to compile the code should generate his own key?
How do you handle this? I feel a little bit uncomfortable with releasing a signature key to the public.
回答1:
For Protocol Buffers, I release the key. Yes, that means people can't actually trust that it's the original binary - but it makes life significantly easier for anyone who wants to modify the code a bit, rebuild it, and still be able to use it from another signed assembly.
If anyone really wants a version of Protocol Buffers which they can trust to be definitely the legitimate one built with the code from GitHub, they can easily build it themselves from the source that they trust.
I can certainly see it from both sides though. I think if I were writing an Open Source project which revolved around security that might be a different matter.
回答2:
Don't release the key.
You SHOULD feel uncomfortable releasing a signature key to the public. It is not the project's signature. It's YOUR signature. The integrity of the signature on the binary is maintained only if you keep your key secret. Releasing the key subverts the meaning and intent of signed assemblies and strong naming, which introduces new possibilities for errors, and thus makes every system less reliable. Don't release the key.
For DotNetZip, I don't release the key. But here's the key point: The key does not belong to the project; it is my key. Many people have asked for the key so they can re-build the signed binary, but that makes no sense. I use the key to sign more than DotNetZip. Any binary signed with that key is signed by me, by definition. Any two binaries that have the same strong name using my key, are guaranteed to be identical. Releasing keys removes those guarantees, and defeats the entire purpose of strong names, and the security surrounding them.
Imagine devs choosing their own version numbers, and re-signing a modified binary with my key. Now the world would have 2 assemblies with the same strong name, but with different contents.
Imagine if I were able to sign any assembly with YOUR key. If you released your key, I could add any code I liked - even malicious code - and then sign it, and surreptitiously replace any "good" signed binary of yours with a "bad" one. No one would be able to tell the difference.
This is broken. Freely sharing keys eliminates any advantage to using signed assemblies at all.
If people want to modify the code in a project and then re-use the modified version in a strongly-named assembly, they can sign the modified version with their own key. It's not difficult.
回答3:
I wouldn't release the key publicly. The whole point of having a signed assembly is that people can trust that you're the only one who touched the binary, and so if there is any illegitimate code added then the signing is off and people know not to trust the assembly.
Signing assemblies protects you from other people adding "bad" code to your binary and pretending it's a legitimate release.
来源：https://stackoverflow.com/questions/396143/net-opensource-projects-and-strong-named-assemblies