.NET: Should executables be strong-name signed? What about private DLLs?

Question

My application consists of three assemblies: a single EXE which references a couple of DLLs. The DLLs are private to my application - they are used only by this executable.

Answer 1

If you sign an assembly, any referenced assemblies are publicly exposed they must be signed too. Otherwise you will get a compile error for good reason.

I think the primary use for strong naming an assembly is to get it into the GAC.

I don't see a need to strong name an exe.

just my 2 pesos....

Answer 2

Strong naming assemblies ONLY ensures version compatibility. This is not the same thing as trusting the assembly.

In other words, the "strong name" ONLY refers to that exact assembly binary in combination with the version number in use at the time of compile.

If you GAC those assemblies, then the CLR will only verify it once. At the time the assembly is gac'd. This can result in a performance improvement. However, my experience has shown it to be minimal.

A strong named assembly can be replaced with one that is not strong named; which brings up the part about strong naming NOT being any type of security feature.

My personal opinion is that the level of pain associated with them does not justify their use. The pain being how they screw with automated testing tools.

https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5054496.html

Answer 3

As I see it, these are the benefits to strong-name signing in this situation:

• Prevents an attacker replacing a DLL with one signed using another key (or not signed at all), without also replacing the EXE (since the EXE contains a reference which includes the public key).
• Prevents an attacker modifying an assembly while retaining the existing key (since this will cause signature verification to fail). Note, however, that as of .NET 3.5 SP1, signature verification in this situation is disabled by default.
• Could prevent the application from running with mismatched versions of assemblies - if a DLL has been incorrectly replaced due to a deployment error, the application will fail to load it rather than trying to use a (potentially incompatible) wrong version.
• Avoids FxCop warnings.

And the drawbacks to signing (I believe these are what the linked article is referring to):

• Replacing a DLL with a compatible newer version (in order to fix a bug, for example) requires replacing the EXE.
• In .NET versions < 3.5 SP1, strong-named assemblies take longer to load due to signature verification.
• Strong-named DLLs also take longer to load because the loader performs a (futile in this situation) search of the GAC before looking locally.

It does seem a shame that the choice is either strong-naming (and thus requiring references to match an exact key and an exact version), or not strong-naming (and not requiring either to match). If it were possible to require a key but not a particular version, perhaps it would be possible to get the first 2 benefits of signing without also getting the first drawback. Maybe this is possible by applying a strong name and then dealing with the versioning issue using app.config?

Answer 4

Signing assemblies ensures that assemblies are not modified after compilation. And as long as you are the only private key owner no one is able to resign the assembly with your key.

Sure, this is not an absolute protection. A hacker can modify assemblies and remove strong name signatures (and references) from all assemblies. These assemblies would also work.

But in such a case you are able to say that the modifications are not made by you.