Say I’d like to release an open-source class library. I’m wondering if I should publish the snk with it or not. I do want an snk to make the dll GAC-friendly for example. I’ve seen big projects with a public snk (NHibernate) and with a non-disclosed one (DevExpress), and also small projects from both sides, so there’s no general agreement, that’s for sure.
Let’s say I don’t publish the private key. The users of this library, who are developers themselves, will either need to recompile my sources if they want to make any changes, or make an exception for the strong name verification. Both a pain in the neck, I’ve been there.
Let’s say I publish it. I fail to see how that can be exploited. CAS and stuff is not in wide use anymore, what’s more, it’s even deprecated in .NET 4.5. So it’s not like poor users grant some rights to my assembly based on its public key token and the bad guys produce a foul assembly with the same token. If a bad guy can put his own dll on someone’s computer, then it’s really not the strong name that’s going to stop them.
I don’t think anyone ever checks the public key tokens of assemblies. Sure, the runtime checks that it hasn’t changed since the referring assembly was compiled, but that’s all. Publishers don’t publish their token, so for all I know, I may reference a foul assembly in the first place when I compile mine.
So I’m leaning towards publishing the snk. Looks to me like it provides little security in theory, no security in practice, so why make lives of my users harder. And maybe I should do X.509 code signing (that one with a really private private key), but I think most people don’t check that anyway either.
To publish or not to publish? The best argument wins. Theoretical side, practical side, MS™ guidelines, all welcome.
You shouldn’t distribute your strong naming key, but that has little, if anything, to do with security.
Strong naming is an identification technique, not a security measure. It is meant to prevent accidental assembly identity collision only. (For it to be strong enough for “serious” security use, it would need to revokable keys instead of self-generated keys.)
However, preventing accidental collision is quite a sufficient reason for not distributing your signing key on an open-source project. It’s the main thing preventing your version 1.2.3.4 from looking identical to a version 1.2.3.4 compiled from modified source by somebody else. Given that one of the primary goals of opening up the source code for a project is usually to allow folks to distribute assemblies compiled from altered code, one might even argue that properly individualized strong naming is more important for an open-source project than for a closed source distribution.