Assembly signing

[Guest]

Just a question. If i have an app with a dll version 1.5 and I replace it
with version 1.6 everithing works fine.
If i change the strong name however the app crash, but this is fine.
My curiosity is then: the various System, System.data and so on are signed?
If so, how can the mono project prot them without having the private key?

this is just for curiosity, no real need,

Thanks!
Cristian Mori

 

[TerryFei]

Hi Cristian,
Welcome to Newsgroup!

Based on DonNet Framework, the assembly resolver goes through in the order
below to find an appropriate assembly file.

the 1st location that the assembly resolver uses to find an assembly is
the global assembly cache (GAC). The GAC is a machine-wide code cache that
contains assemblies that have been installed for machine-wide use. The GAC
allows administrators to install assemblies once per machine for all
applications to use. To avoid system corruption, the GAC accepts only
assemblies that have valid digital signatures and public keys. 2nd, If the
assembly resolver cannot locate the assembly using the GAC, it performs a
search through a series of directories relative to the root directory of
the application. This search is known as probing. Probing will search only
in directories that are at or below the APPBASE directory (recall that the
APPBASE directory is the directory that contains the application's
configuration file).

The Mono is the third party project. From my experience, it should also has
one similar algorithm to locate the assembly file. If you want to get more
details, you can consult it from the relevant Mono Web Site.

I hope the above information is useful for you. If you have any questions
or concerns, please feel free to let me know.

Best Regards,

Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

Hi Terry, Thanks for your reply.

Thanks for the explanation, but I still miss one thing.
Id I use system.Data, my app will have the public key of the signed
assembly, in order to decript it at runtime.
If I take my app and I move it in a mono system, the same app runs without
recompiling, and this is the "magic" of .NET.
However, how could it be possible if the two assembly (.NET Framework and
Mono Version) doesn't have the same strong key?

Thanks
Cristian

 

[TerryFei]

Hi Cristian,

For the execution of the .Net application, all its referenced assemblies
should be found. If not, the application will not run. In Microsoft .Net
Framework, the CLR(common language runtime) will load the referenced
strong-name assembly from GAC or its private directory according to the
probing steps listed at the previous post.

It should be the same in MONO. When MONO loads the application, it should
search the referenced assembly and then load it for the execution. Since
MONO is a virtual machine as the same the MS .net CLR, it should have the
corresponding location to store the strong-name assemblies, as the GAC in
MS .Net.

For your scenario, MONO should firstly locate the System.Data from its GAC.
Then the application could run smoothly. This is the reason why your
application could run without any error.

Best Regards,

Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[Guest]

OK, but I still miss one think.
If I use Syste.Data in my app, then the public key of system.data is stored
in my app and it is used to decript the assembly when loaded.

Moving to mono, my app still use the stored public key of system.data (the
microsoft .net one) to decrypt and load the System.Data of mono.
So I guess that the System.Data of mono must be signed with the same key of
the microsoft one.

What am I missing?

Cristian

 

[David Levine]

You can use sn.exe, reflector, or some other program to determine what the
public key token is of the system assemblies in mono and compare them to
those used by the commercial release of .net. This will provide more
evidence that can be used to figure out what is going on.

OK, but I still miss one think.
If I use Syste.Data in my app, then the public key of system.data is
stored
in my app and it is used to decript the assembly when loaded.

Moving to mono, my app still use the stored public key of system.data (the
microsoft .net one) to decrypt and load the System.Data of mono.
So I guess that the System.Data of mono must be signed with the same key
of
the microsoft one.

What am I missing?

Cristian

Hi Cristian,

For the execution of the .Net application, all its referenced assemblies
should be found. If not, the application will not run. In Microsoft .Net
Framework, the CLR(common language runtime) will load the referenced
strong-name assembly from GAC or its private directory according to the
probing steps listed at the previous post.

It should be the same in MONO. When MONO loads the application, it should
search the referenced assembly and then load it for the execution. Since
MONO is a virtual machine as the same the MS .net CLR, it should have the
corresponding location to store the strong-name assemblies, as the GAC in
MS .Net.

For your scenario, MONO should firstly locate the System.Data from its
GAC.
Then the application could run smoothly. This is the reason why your
application could run without any error.

Best Regards,

Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

 

[TerryFei]

Hi Cristian,

The SN.exe utility of .Net Framework is used to generate public key for
assembly and it ensure the produced key globally unique. As I know,
Microsoft should not have shared the public key with MONO. So the
System.Data assembly of mono should not has the same public key as the same
to .Net System.Data Assembly. So I think MONO should has some internal
implementation to support referencing .Net provided strong-name assembly,
for example System.Data etc. This should be one MONO compatible design.

Best Regards,

Terry Fei[MSFT]
Microsoft Community Support
Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)