Chapter 9. Understanding the Concepts of Strong Naming Assemblies

for RuBoard

By Rudi Martin

IN THIS CHAPTER

• Assemblies and Identity

• Public/Private Key Pairs

• Signing and Verifying Assemblies

• Delay Signing Assemblies

• Comparison with Authenticode Signatures

Within the Windows environment today, there exists a serious code deployment problem commonly referred to as "DLL Hell." This situation arises when multiple applications share common code ”usually in the form of a dynamic link library, or DLL. Each application may require features from the DLL that are specific to a particular version of that code; therefore, it is common practice for applications to ship their own copies of shared DLLs as part of their main product deployment. During product installation, these updated DLLs may overwrite any previous version already installed.

This leads to severe management problems. Installing one application may cause previously installed applications to begin failing due to version incompatibilities with the new copy of the shared DLL. Such problems are hard to isolate and track down, especially because they might not be noticed at once. Furthermore, even once the offending DLL is pinpointed, simple solutions may not be available. Simply reverting the DLL to its previous state (a nontrivial task in itself) might render the application that updated the DLL inoperative.

DLL versioning might seem to be the answer to this problem (during installation, simply select whether to keep an existing DLL or update it with the supplied copy based on the embedded version ”the most recent version wins). This is problematic for a number of reasons:

• Version updates are not always backwards compatible. While every effort should be made to ensure backwards compatibility, sometimes this is an impossible goal. So installing a later version of a shared DLL might conceivably break some applications.

• It's possible that an application publisher may take a copy of a commonly shared DLL and include additional functionality before distributing the updated DLL. While this is not good practice, it does happen. This creates a branch in the DLL versioning scheme that makes identifying a highest version impossible.

• Sometimes the clash in DLLs is purely accidental. The DLLs are unrelated and merely share the same name . This can happen relatively frequently when short DLL names are chosen and installation is performed into a heavily shared area of the operating system's file system, such as the Windows system directory.

The .NET Framework solution to this problem is to allow multiple versions of a piece of code to coexist peacefully together, allowing applications to use whichever version with which they are known to work. This is known as side-by-side support, and a full description of the topic is outside the scope of this book.

Strong names play a part in the side-by-side story by providing a mechanism to name code in an unambiguous fashion, avoiding the problem of accidental namespace collision previously mentioned. They also provide a means of ensuring that no one can modify or extend the code belonging to another publisher, which serves to simplify the management of shared code and has interesting security ramifications of its own.

This chapter introduces the .NET Framework concept known as a strong name. Upon completion of the chapter, you should have a grasp of the following:

• Outlines of the problems strong names are designed to solve

• Concepts and terminology used when dealing with strong names

• The high-level algorithms used in the design and implementation of strong names within the .NET Framework

• The differences between strong names and Authenticode signatures

NOTE

Further information regarding the use of strong names within the programming environment can be found in Chapter 25, "Implementing a Secure Assembly."

To understand the concept of strong names, you must first look at the assembly, a new concept introduced by the .NET Framework.

for RuBoard