Anything wrong with NOT signing a .NET assembly?

One of my colleagues is very keen on signing assemblies. He literally tries to sign anything. Even when we use assemblies from Microsoft that are not signed, he will take the source code, sign it and then ask other developers to use his copy instead.

I can understand the basic idea behind signing an assembly: to ensure a particular assembly is not compromised by some dodgy hacker. So if we are a software development company, we should sign our assembly before releasing some .NET library to our customers.

However, we primarily develop web applications for our own use here, and I just can't see the point of signing every single assembly we use.

Am I missing something here?

I've taken advantage of non-signed assemblies to get around issues before and in academic settings shown people why it's important. I replaced a DLL file that was unsigned (again in an academic setting) with one I made with the same name, same signatures, and used .NET Reflector to copy and paste the original code, but in mine I emailed user names and passwords that were being passed in before calling 'real' code.

If signed, you can make a signature match, but not replace. Contrary to what Zippy says, there will be a run-time compliation error.

Signing assemblies is never overkill. It takes 30 seconds. It's like saying locking your doors is overkill if you live in the country. If you want to gamble with your belongings, go ahead, leave it open. It only takes one security breach to get fired. It only takes 30 seconds to sign an assembly and there's no business case not to. The performance impacts is negligable.

Signing assemblies that are used within a trusted environment sounds like overkill to me.

An interesting point on signed assemblies is that they are slightly slower to load than unsigned assemblies, as they must be cryptographically verified.

In order to sign an assembly, any assemblies it depends upon must also be signed. My guess is that this contributes to your colleague's desire to sign everything -- the compiler is demanding it.

EDIT Since writing this answer you can see both the pro and against camp have roughly equivalent support. There clearly isn't a right answer here.

The point that compelled this edit though is that nowadays we take so many open source libraries from NuGet, and many of them are not signed at all. If you wanted to sign your assembly, you'd need to have any dependencies signed too. Many of the open source libraries that are signed have the private keys used for signing publicly available in their source repositories.

As with everything there are trade-offs to be made. In my experience of working in private environments, the benefits of signing are mostly theoretical (or academic, as @user289100 mentions), unless you're concerned about government agencies modifying your code in which case you need to be paranoid about so many levels of your infrastructure that signing would seem like a small amount of effort. Otherwise the amount of challenges that cascade out of having to sign everything just don't seem worth it. However your environment may have different requirements, or you may be a masochist!

See also Teun D's answer for information on challenges related to versioning assemblies when using strong names.

One additional point: signing your assemblies breaks backward compatibility over versions. Your references all start to include version numbers and versions with other version numbers are considered non-compatible. This hinders upgrading to newer versions of distributed assemblies.

In my opinion, you should only code-sign assemblies if you see some concrete gain from it:

• if you deploy to environments where untrusted people might touch your assemblies
• in certain plug-in models, where you want to use the certificate as evidence for upgrading the trust
• if your code should be callable from other signed code (a project like, say log4net, justifiably signs their code to be widely usable; they messed up hugely in compatibility by losing their secret key a few years ago, another risk of code-signing).
• if you want to deploy to the GAC

Has your colleague given you any indications as to why he likes to sign assemblies? One advantage to signing that hasn't been discussed here yet is that only signed assemblies can be put in the GAC (i.e. be shared across managed processes), but the downsides do seem to outweigh the upsides from my (admittedly inexperienced) perspective.

Your anecdote about self-signing Microsoft code seems particularly suspect to me. If MS didn't sign the code, there's probably a reason, right? And by signing it, you're taking responsibility for it when you didn't write it - another opportunity for the future to bite you.