What is the recommended way to manage a strong-name key pair for an open-source project?

Question

I manage an open-source project and would like to sign the binaries that are released in the project's binary package. I use Visual Studio csproj and sln files to manage and build my project, and also distribute these files as part of the project's source packages.

How can I sign the produced binaries of my build and not have to distribute the snk key-pair file? If I use Visual Studio to sign the assemblies, each project file now needs a copy of the key-pair in order to build. I'm not comfortable with distributing the key-pair, even if it is password protected.

Edit:

Another caveat is that some assemblies in the project grant friend access via InternalsVisibleToAttribute, and build those friends via a project reference. Consequently, such assemblies need to use a strong name when referring to a signed assembly. However, if the key-pair is not distributed then how can end-users build the sources and maintain the project relationships? If a temporary key-pair file is used, won't the public key token of the signed assemblies change, breaking the InternalsVisibleToAttribute references?

Answer 1

You should not distribute the keypair. The strongname is for verifying that the new version of assembly comes from the same publisher.

If another developer wants to branch your project they will generate their own keypair and that will effectively show that their version is not from you so that other assemblies that depend on yours will not load anymore unless they are recompiled. That's not always convenient but it protects you from someone issuing a malicious version of assembly and silently distributing it.

Answer 2

This is an old question, but the currently highest-voted answer is not accurate, so I figured it's worth posting a new answer.

For open source projects, Microsoft recommends checking in your private key into your repository. This is safe because strong name keys are used for identity, not security.

See here for reference: https://docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies

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

They also specifically address open source projects:

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.

If you want security for your assemblies, then you should look into Authenticode signing: https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/