.NET Security: CAS vis-à-vis Migrating 1.1 code base to .NET 2.0: StrongNameIdentityPermission
WCF Duplex contract / Message broker endpoints, and GetHashCode()

Visual Studio 2005/2008, "Delay signing" message text fuss.

Many people have asked about this to me, with a hesitation in their minds to delay sign their assemblies, given the message text that sits in the "Signing" tab page in Visual Studio (2005 and 2008) Project settings view.

Hence I thought I will blog my replies on this anyway, just so that it could be useful to all others out there with the same worry in mind.

When you attempt to setup partial signing, you can get confused or worried by the message that you see in the bottom of "delay signing" checkbox in Visual Studio setting page.

Delay signing

This is the message that gets people worried (at least at the first look/instance) and gets them thinking if they should skip delay signing completely.

To be frank, that message you see there, is not worth so much of importance as-is. I know what MS is trying to say there, but they have not used the correct message text to convey what they intended to say :-)

All that MS would want to convey there is that if you did delay signing, then (specifically for VS 2005) the hosting process - i.e. the <App name>.vshost.exe will attempt to block any debugging activity once the delay signing switch set to ON is detected.

This was the case at the time of VS 2005. This has been addressed now.

Also, the message is trying to say one other thing - I.e. since you will be signing only with a  part of the full key pair when delay signing our app, the crypto bytes that gets into the assembly manifest will end up being null/0 bytes - which is expected.
But when the app is run, the CLR (runtime verification process) will detect this fact and then fail to load the assembly, since the encrypted hash will be 0 bytes, it will be taken as a tampered assembly, and hence will fail the .NET security verification process, and will end up throwing a FileLoadException, and consequently won't run the assembly.

Hence the message that you see in the Signing tab in the page saying that if you delay sign it, you won't be able to debug or run the assemblies.

But it is not fully correct on the part of MS to say what it says there, with just those words in there, because it can lead you to be confused.

What actually will happen is, in the context of development builds / tests / debugging, we will (obviously) need to switch off the run-time verification process - i.e. via the sn- Vr / secpol toolset + through our local development build scripts / process, which we will do anyway, if we are building delay signed assemblies, and will be debugging it for development tests, et al.

But what Microsoft overlooked (and continues to do so) is the fact that those who delay sign the assemblies will know to switch off the verification process in their sandbox / development machines in order to be able to debug the apps, and they simply came up with that message text that you see in the Signing page in VS 2005/8 setting page :-)

Although this may sound a trivial issue, it will be good on the part of MS to fix this message text in Visual Studio. This has been around from the time of VS 2005, but it is annoying to see this not addressed even in the VS 2008 release.

MS should either change the text, so as to make the information clear, or the note should be completely removed altogether.

I would personally favour the later option, since the host (vshost.exe) does not anymore detect this setting  and disable debugging facilities (as it used to do in the early VS 2005 times), and also considering the fact that developers / teams who will be delay signing their project do know what they should prepare in order to debug/run their delay signed assemblies.

Anyway, until MS addresses this, rest assured that there is no need to get confused or alerted by that little (partially) incorrect message :-)

You can delay sign your apps, and run them, debug them et al.

Just ensure that your development build process has the scripts setup to switch off the run-time verification process.

That said, it is not advisable to simply switch off the run-time verification on all assemblies, since that can bring in security risks to your development machine.

Instead switch off the verification process only based on your delay signed assemblies's public key part token, with which you can then run a command something like this:

sn -Vr *, <your delay signed assemblies's public token part of the full secure key pair>.

- Sundar

Comments

Rajeesh

Thanks for the reply. Now it is clear.

Ta,
Rajeesh

Sundar

Cheers Rajeesh. Glad you liked the post :-)

Regarding your question:

The thing is that a delay signed assembly will contain the "public key" token of the "signing key" but will not contain an "actual" digital signature. This is what will be null / 0 bytes.

Inside the PE file produced produed by the compiler, this "delay signed" assembly will be made to contain "space" reserved for a signature to be placed (at a later point in time - i.e. when this is re-signe with the full secure key), but the space that is reserved to store this digital signature will actually be just a block of zeros until the real signature is computed. Since this block is not likely to be the actual signature value of the assembly (i.e. containing 0s), this assembly will fail to verify upon loading. (since the digital signatures is invalid - i.e. just 0s).

So the point is, the delay signed asembly will have a public key stored in it, but that is not very important in terms of the verification process.

The important bit is that the assembly will not contain the valid "digital signature" which the run time will have to use to decrypt for its verification process.
This "digital signature" will be a set of 0s in a delay signed assembly, until is fully signed (as part the final build process) :-)

Now, is it clear? :-)

Rajeesh

Hi Sundar,

Nice article, these days I was trying learn about signing, security etc..

When I read through the article and doubt came across my mind. You said in the article that when we delay sign the assembly the crypto bytes that gets into the assembly manifest will end up being null/0 bytes , why is that hash becomes 0 bytes, because delay signed assembly should contain the public key token information, is it?

Ta,
Rajeesh

The comments to this entry are closed.