What is the point of making assemblies strong named?

[bobthebuilder999]

As I understand it, one of the purposes of making assemblies strong
named is to stop the assemblies from being tampered with. How does this
work?

As a test, I did the following:

-Created an Assembly called ServerApp, containing a single class
ServerObj, which had a single function Calculate, that simply doubled a
parameter passed to it and returned the result.

-Used the sn.exe tool to create a key and compiled ServerApp,
referencing the key in the AssemblyInfo file.

-Added the assembly to the GAC using gacutil

-Created a client that referenced ServerApp (with Copy Local set to
false) and tested

-This worked as expected so I then modified ServerApp to return 0 from
Calculate (i.e. I deliberately got it to 'fail') and recompiled it,
this time without referencing the key, so the dll was not strong named.

-Using a command prompt I then copied the new dll to the GAC,
overwriting the old version (i.e. I didn't install it in the GAC, I
just replaced the file with my 'bad' version).

-I ran the client (without recompiling) and it returned 0 (i.e. it
picked up the bad, unsigned version).

Shouldn't this have failed somewhere or do I have some fundamental
misunderstanding.

 

[Richard Blewett [DevelopMentor]]

The crucial thing here is you used the GAC. GAC'd assemblies are only verified when they are put into the GAC not when they are loaded from it. This is unlike other strong named assemblies which are verified every time they are loaded.

However, you have to be a power user or administrator to put an assembly in the GAC due to the ACL on the directories so as either of those roles there are all sorts of things that you could do apart from tamper with assemblies.

I do believe, however, that the GAC should only be able to be updaed by administrators not power users and there is an argument to be made for always verifying an assembly irrespective of where it was loaded from.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

As I understand it, one of the purposes of making assemblies strong
named is to stop the assemblies from being tampered with. How does this
work?

As a test, I did the following:

-Created an Assembly called ServerApp, containing a single class
ServerObj, which had a single function Calculate, that simply doubled a
parameter passed to it and returned the result.

-Used the sn.exe tool to create a key and compiled ServerApp,
referencing the key in the AssemblyInfo file.

-Added the assembly to the GAC using gacutil

-Created a client that referenced ServerApp (with Copy Local set to
false) and tested

-This worked as expected so I then modified ServerApp to return 0 from
Calculate (i.e. I deliberately got it to 'fail') and recompiled it,
this time without referencing the key, so the dll was not strong named.

-Using a command prompt I then copied the new dll to the GAC,
overwriting the old version (i.e. I didn't install it in the GAC, I
just replaced the file with my 'bad' version).

-I ran the client (without recompiling) and it returned 0 (i.e. it
picked up the bad, unsigned version).

Shouldn't this have failed somewhere or do I have some fundamental
misunderstanding.


[microsoft.public.dotnet.framework]

 

[bobthebuilder999]

Thanks for your help - this makes sense now. I do agree that there is
argument for verifying the assembly even if it is in the GAC.

Toby Austin