Anything wrong with NOT signing a .NET assembly?

Question

Hi,

One of my colleague 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?

Answer 1

I agree it seems like a bit of a waste. It's really needed to ensure the file is what you think it is (and hasn't been tampered with). But if you trust the confines of your own network security and web server, then signing your web assemblies seems like a redundant step.

But maybe that's my small-business experience talking. If you're talking about a mission-critical online banking website, then sign away.

Answer 2

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.

Answer 3

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.

Answer 4

Another thing about signing an assembly is, that one can't inject incorrect one in place of yours (also - yourself by an accident). In example, if you create a program that refers to an assembly Foo.dll, version 1.0, someone can create the an assembly, with the same version, and replace yours, when you sign your library, it won't be possible (at least I don't think it's easily possible).

Answer 5

Signatures are only necessary if the assemblies are placed in the GAC, nothing else. Signed assemblies do not prevent someone to mess with them. A hacker can still strip of the signature and any other code that checks for the signature.

Answer 6

Think about doing it if you're going to ship something and/or actually have a reason to do it. In every other case, it's just hassle. I'd ask your workmate what he actually gets out of doing this.

I've encountered signed assembly-itis before and it's a pain in the posterior, especially when you consider the amount of people who have little to no knowledge of signing assemblies, what it's for and how to do it. It's just another thing you shouldn't have to concern yourself with unless absolutely necessary.

Answer 7

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

Answer 8

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 that was unsigned (again in an academic setting) with one I made with the same name, same signatures, and used 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 signuature 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 assembly and there's no business case not to. The performance impacts is negligable.