Why can't strongly named assemblies use assemblies that aren't signed?

Question

To sign an assembly A you have to make sure all assemblies B, C, D that are used by A are signed, and then all assemblies that are used by B, C, D, and so on. I don't understand what's the security benefit of this. I think it's supposed to prevent tampering, but assembly A is allowed to open any file, and these can be tampered. The same goes for an external webserver.

Also, it's too easy to sign an assembly with a .snk file that you make public, sidestepping the requirement.

Answer 1

The point is that otherwise you could replace assembly B/C/D with a different (hacked) one, and A would never notice; it would load them and execute the code. With strong naming, you can't do this without either re-signing the hacked B/C/D with the same key, or by hacking A.

Answer 2

Another reason for strong naming is versioning. If you reference a strong named assembly, you get that specific version - and it will load its dependencies at the specific versions it relies upon.

EDIT

Example scenario: If you put an assembly in the GAC, it has to be strong named to allow side-by-side versioning. You couldn't put it in the GAC, though, unless its dependencies were also there (otherwise, they'd fail to load at run time). In order for those assemblies to be loaded reliably, they need to be strong named too, and in the GAC.