Any security issues adding a strong name key to source control for an open source project?

Question

Given a Strong Name Key (snk file). Is there any security issues adding this file to source control for an open source project?

Retard

Answer 1

The simple answer is yes and no -- it depends on the purpose for which you are strong-name signing your assemblies in the first place.

The MSDN page on Strong-Name Signing summarises the two purposes fairly well.

Strong-naming gives an application or component a unique identity that other software can use to refer explicitly to it. For example, strong-naming enables application authors and administrators to specify a precise servicing version to be used for a shared component. This enables different applications to specify different versions without affecting other applications. In addition, you can use the strong name of a component as security evidence to establish a trust relationship between two components.

Any publicly-distributed library (DLL) should be strong-name signed, as long as it is intended to be consumed by the end-user. (i.e. Unless it is an implementation detail or such.)

The primary purpose of signing that I have seen tends to be for more technical reasons, including unique identification (namespaces can sometimes inadvertently clash) and making an assembly available for the GAC. In such cases, making the key file publicly available has no security implications, because none were intended in the first place. No guarantees of trust/origin are provided, but unique identification is still valid. The MSDN page mainly discusses this scenario; the times when you should and should not sign an assembly; and the surrounding details.

If however, you are signing an assembly for the sake of authentication -- specifically, to provide a guarantee to the consumer that the assembly comes from the claimed source -- then an exoteric (publically-distributed) key utterly invalidates this trust model. That is, anyone can go modify your project code arbitrarily, and rebuild and resign your assemblies correctly, essentially faking your identity. The MSDN page does not address this usage well unfortunately (probably because it needs to be considered more widely as part of a security strategy), but it is important nonetheless.

Finally, be aware that there are two types of key certificate files that the CLR/.NET uses to sign assemblies. The first is an SNK, as you mention; this is non-password-protected. The second is PFX, which is really just a password-protected version of an SNK key file. As long as this password is sufficiently secure, there is hence no security problem in distributing a secured PFX with your open-source software. Visual Studio (and the command-line key generation utility) are of course capable of creating both.

Conic

You may also want to see this answer <https://mcmap.net/q/142884/-what-is-a-snk-for> and extrapolate appropriately for PFX key files. – Conic

And sn.exe is the strong-name creation/manipulation utility that you want if running from the command-line. It provides a fair few features, most of which you'll probably never need. msdn.microsoft.com/en-us/library/k5b5tt23%28v=vs.100%29.aspx – Conic