Why use delayed signing

Sometimes I hear the question, why not just share the private key with the developer team in order to avoid the whole process of resigning an assembly before deployment.  Well the answer is all about protecting the integrity of your systems and software.  At Microsoft we are proponents of using delayed signing for development and keeping the private key under lock until we are ready to deploy an application.  Only a very small group of individuals ever has access to the private key as this represents our official signature for signing an assembly.  If you delay sign the assembly and deploy it, as is,  the runtime will assume that the assembly has been tampered with, and will fail to load it.  So delay signing during development coupled with strong name signing at deployment helps protect the integrity of your systems and software and prevents spoofing of your code.  Without access to the private key, a malicious user cannot modify your code and successfully re-sign it.

Signing is about governance, putting processes and policy in place to protect your systems and software from inappropriate use or access by direct (people) or indirect (code) means.  IMO it’s equivalent to asking why it is not ok to give developers Admin level permission on production servers?

See the following 2 articles for more information on when/why/how you should use strong-name and delayed signing http://msdn.microsoft.com/msdnmag/issues/06/07/CLRInsideOut/, http://msdn.microsoft.com/msdnmag/issues/01/03/buildapps2/.

Comments (0)

Skip to main content