I've been thinking about just how Strong Names in .NET (as generated by SN.EXE) and Open Source libraries should be mixed,
and I must admit I haven't quite made up my mind, yet. I started thinking about this after Simon's
and Peter's recent discussion
on the security merits of strong named assemblies.
Peter quite correctly states that "...the public key in the component assembly manifest lets us confirm that the signature could only have come from someone who has the matching private key, which is protected (right?) with the appropriate degree of pomp and circumstance.". So here's the rub: If your library is open sourced, and it should also be strongly signed (as I believe in most cases should be), what happens to the private key used to sign it?
Many .NET open source projects seem to be distributing the full keyfile generated by sn.exe containing both the private and public keys. This is sensible in that it allows anyone else to easily rebuild the assembly as needed, but it also defeats part of the security stated above. After all, once you have the private key, you could easily resign a modified assembly that did whatever it wanted. The obvious solution would be not to distribute the key at all, and instead retain control of it with the project's core members/leaders. This makes it more annoying for a third part to rebuild the library from the sources, as they'd need to generate a new private key to sign it with, but I'm starting to think this makes an awful lot of sense. After all, if someone else rebuilt the library, it obviously doesn't come from the same team that built it originally, does it?
So, what does anyone else think? What would be the right thing to do here? And, since we're on the topic of strongly signed assemblies, how many people are actually using delayed signing and tightly kept private keys in their work environment, and how well is it working out for you?
