Delay Signing Assemblies

for RuBoard

Within a development environment, it might not always be feasible or convenient to gain access to the publisher private key to strong name the assemblies being built. This is a consequence of the need to keep the private key secure ”if the key is easily available to the development team, it is increasingly difficult to ensure that the key is not compromised or even to detect such a compromise should it occur.

Consequently, many publishers will keep the private key in a secure location, possibly embedded in specially designed cryptographic hardware. Strong name signing assemblies then becomes a heavyweight process because all assembly creation within the publisher is channeled through a single location. With multiple developers building multiple assemblies many times a day, this constriction can swiftly become the chief bottleneck of the development process.

Merely removing the strong name from assemblies during development does not provide a satisfactory workaround due to the identity change involved. That is, removing the publisher public key from the assembly name changes its identity, a change with ramifications just as severe as altering any other publicly visible aspect of the assembly. For example, dependent assemblies will need to be rebuilt after the public key is added to update their references with the correct public key tokens. Even worse , some references to the development assemblies may be present in code in the form of text strings (most likely in the case of late bound references). These references will not be automatically updated via a rebuild and, due to their nature, the errors will not be revealed until runtime.

Problems such as these can pose unacceptable risks to the project ”the introduction of strong names in the late stages of the development cycle can invalidate previous testing and potentially introduce or uncover hitherto unseen problems, all at the worst possible time.

A solution to this dilemma can be found by noting two important facts:

• The only publicly visible aspect of strong names ”and thus the only aspect that should impact dependent assemblies ”is the public key component of the assembly name.

• The cryptographic security of assemblies under development is not generally an issue; developers are building their own versions of these assemblies and are unlikely to be downloading versions from any outside source.

With these points in mind, we introduce the concept of delay signing. Delay signing is a technique used by developers whereby the public key is added to the assembly name as before, granting the assembly its unique identity, but no signature is computed. Thus, no private key access is necessary.

Although delay signing does not compute a signature for the assembly being built, it does cause the space necessary for the future signature to be allocated within the image. This makes it a simple task to compute (and, if necessary, to recompute) the signature at a later date without the necessity of a full assembly rebuild. This is advantageous because it reduces the complexity of the signing process ( bearing in mind that the actual signing may be performed in a secure location where it may not be possible or desirable to re-create a full build environment). Signing in such a fashion also minimizes the differences between development and release versions of the assemblies, boosting confidence that test and quality assurance passes on the development versions haven't been invalidated by the signing process. To further aid this, utilities packaged with the .NET Framework (such as the command-line tool sn ) can confirm assembly images differ only by their signatures ( uninitialized , delay signed state to initialized , fully signed state) and that the resulting assemblies have self-consistent signatures.

Delay signing introduces a problem of its own, because the resulting assemblies will no longer pass strong name verification and will become essentially useless. To enable their use, the strong name verification rules need to be relaxed . Development and test machines (or any machine that is to use prerelease versions of the assemblies) can be taught to skip strong name verification for the affected assemblies. This is achieved through the use of entries in the machine's registry ”manipulated through the SN management tool ”that lists the assemblies or groups of assemblies to skip.

For example:

 SN Vr MyAssembly.dll 

This command will turn off strong name verification for just MyAssembly.dll . To turn off strong name verification for all assemblies with the same public key token, something like the following example can be used:

 SN Vr *,b03f5f7f11d50a3a 

For a full description of managing strong name verification using the SN utility, see Chapter 25.

Obviously, such a technique must be used with care to avoid opening security holes. Adding such entries to the registry removes the safeguards in place when downloading code claiming a strong name based on the publisher's own public key. Administrative privilege is required by the user to add such registry entries and, in addition, the default security policy shipped with the .NET Framework limits registry access to locally installed assemblies only.

Detailed information on building delay signed assemblies and setting up environments in which they can be used is found in Chapter 25.

for RuBoard