Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

.NET OpenSource projects and strong named assemblies?

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.

like image 366
Martin C. Avatar asked Dec 28 '08 12:12

Martin C.


People also ask

What makes a strong named assembly in .NET framework?

What makes a strong-named assembly? A strong named assembly is generated by using the private key that corresponds to the public key distributed with the assembly, and the assembly itself. The assembly includes the assembly manifest, which contains the names and hashes of all the files that make up the assembly.

Should I strong name my assemblies?

You should strong name your open-source . NET libraries. Strong naming an assembly ensures the most people can use it, and strict assembly loading only affects . NET Framework.

How do you tell if an assembly is strongly named?

To determine if an assembly is strong-typed, use the Strong Name Tool from Microsoft (http://msdn.microsoft.com/en-us/library/k5b5tt23(v=vs.71).aspx) by running the 'sn.exe -v <assembly>' command. You may need to download one of the Windows SDK packages to get access to this tool.

What is strong name in net Assembly?

A strong name consists of the assembly's identity—its simple text name, version number, and culture information (if provided)—plus a public key and a digital signature. It is generated from an assembly file using the corresponding private key.


2 Answers

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.

like image 69
Jon Skeet Avatar answered Oct 10 '22 01:10

Jon Skeet


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.

like image 38
Cheeso Avatar answered Oct 10 '22 03:10

Cheeso