Why is it recommended to include the private key used for assembly signing in open-source repositories?

Question

According to MSDN, it is a recommended practice to include both the private and public keys used for strong-naming assemblies into the public source control system if you're developing open-source software:

If you are an open-source developer and you want the identity benefits of a strong-named assembly, consider checking in the private key associated with an assembly into your source control system.

This is something that confuses me greatly. Making the private key public? Wouldn't the whole purpose and security of asymmetric cryptography be defeated in this case?

I see in the same article this note:

Do not rely on strong names for security. They provide a unique identity only.

This does not help reduce my confusion. Why then use a private-public key pair if security is not the aim? Is the strong-naming mechanism in .NET using private-public key pairs in an inappropriate way? My guess is that I'm missing or misunderstanding something.

Answer 1

Strong name signing is not for security, it is to guarantee uniqueness. It is so if two people make Foo.dll v1.0.0.0 you have a way of telling them apart in the GAC.

If you have a open source library and you want your end user's MyOpenSource.dll v1.0.0.0 to be able to be used as a replacement for the released MyOpenSource.dll v1.0.0.0 then both the user's copy and the official copy must both be signed with the same key (or both must be not signed at all). That is why you would want to distribute it.

The strong name key is not for saying "This is a official, unmodified copy of MyOpenSource.dll", that is what Authenticode signing is for. It is only for preventing name collisions from different publishers.