Strong Name assembly question

  • Thread starter Thread starter ~~~ .NET Ed ~~~
  • Start date Start date
N

~~~ .NET Ed ~~~

OK this is the setup I have in which I am experiencing a problem:

1. I have written an application with about 6-7 satellite assemblies
(dependents). These are all mine and
get compiled by me. They all -including the application- have been
signed with a strong name key.
2. The application also makes use of 1 third party binary-only DLL/assembly.
As said there is no source code
available for this one, and it is NOT a strong name assembly.

Now here is the catch-22, for my application to be strong named (because it
will have a LicenseProvider),
all the dependent assemblies also need to be strong named. This is no issue
for my assemblies, the problem
arises with that third party assembly that is not strong named!

So, what happens now? I cannot strong name my application because of one
single third party
assembly? I really wouldn't like to sign the 3rd party assembly with my key.
I can also *not* get rid of that 3rd
party assembly. It seems to me like some sort of chicken and egg. Any hints
in this respect are appreciated.

Cheers,
E.
 
The protection that you are trying to circumvent exists for a very good
reason. Before trying to bypass it, have you asked the third party provider
of the assembly whether they would be willing to supply a strongly named
version? A "no" answer should probably be viewed as very suspicious, and it
might be a good enough reason to not trust the provider sufficiently to use
their code at all...
 
Well, one of them probably won't be willing to satisfy the "wim" of a single
user. The other is a control
from some Microsoft Employee that retrieves the SID, something I had been
looking for for a long
time. But I have been doing so much searching that I honestly no longer know
what was his URL
and therefore I cannot ask either.

This basically means that if you use a (free or not) third party assembly to
avoid having to reinvent the wheel then you cannot use it to provide your
own strong-named solution. Unless of course.... one has a lot of time to
spare to go about re-inventing the wheel :( I don't have that much time in
my hands right now.

Seems like I am stuck on this one then at a very crucial point.
 
As a work-around you could always run ildasm and dump the IL, then rebuild it using ilasm but this time give it a keyfile via the /key compiler flag. But in general, as Nicole says, the protection is there for a reason so if you are using a utility to got from the internet, just for your own protection you should make sure you get the source. Regards Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog Well, one of them probably won't be willing to satisfy the "wim" of a single
user. The other is a control
from some Microsoft Employee that retrieves the SID, something I had been
looking for for a long
time. But I have been doing so much searching that I honestly no longer know
what was his URL
and therefore I cannot ask either.

This basically means that if you use a (free or not) third party assembly to
avoid having to reinvent the wheel then you cannot use it to provide your
own strong-named solution. Unless of course.... one has a lot of time to
spare to go about re-inventing the wheel :( I don't have that much time in
my hands right now.

Seems like I am stuck on this one then at a very crucial point.
 
~~~ .NET Ed ~~~ said:
Now here is the catch-22, for my application to be strong named (because it
will have a LicenseProvider),
all the dependent assemblies also need to be strong named. This is no issue
for my assemblies, the problem
arises with that third party assembly that is not strong named!
Click to expand...

Perhaps you could store a hash of the binary file in your app. Do not
design-time bind that dll, but rather load it via runtime loading only (I'm
assuming it's a .NET assembly) via the Assembly class's ability to create an
assembly from a byte array representing the assembly in question. Ensure the
hash of the file is correct, and if so, open it in a stream, read it in,
close the stream, construct the assembly and go from there.

</idea>
 
Chris Hornberger said:
Perhaps you could store a hash of the binary file in your app. Do not
design-time bind that dll, but rather load it via runtime loading only (I'm
assuming it's a .NET assembly) via the Assembly class's ability to create an
assembly from a byte array representing the assembly in question. Ensure the
hash of the file is correct, and if so, open it in a stream, read it in,
close the stream, construct the assembly and go from there.

</idea>
Click to expand...

Wow, I'm an idiot. I completely misread the question. Disregard.
 
~~~ .NET Ed ~~~ said:
Well, one of them probably won't be willing to satisfy the "wim" of a
single
user.
Click to expand...

It's not a whim. It's a very real and very common requirement. There are
really only three reasons that a developer might distribute components that
are not strongly named: ignorance, laziness, or malicious intent. Failure
to strongly name a distributed component is a bad sign. Failure to meet a
customer request to strongly name a component is a _very_ bad sign.

The other is a control
from some Microsoft Employee that retrieves the SID, something I had been
looking for for a long
time. But I have been doing so much searching that I honestly no longer
know
what was his URL
and therefore I cannot ask either.
Click to expand...

Have you looked at the assembly properties (both the Windows file properties
and the assembly attributes using Reflector)? These might help identify the
author. You might also have some luck running an internet search for the
assembly name, main assembly namespace, and/or the name of the package file
(e.g.: zip archive) that you initially downloaded.
 
If the source isn't distributed with a component, chances are pretty good
that its license might prohibit reverse engineering and decompilation.
Also, unless one performs a thorough code review, recompiling the component
won't do much to resolve the underlying problem which, IMO, remains one of
whether one can trust the code enough to use it.
 
The OP states that it was a sample he picked up off a website that he can no longer remember or find. He states that he got it from an MSFT person and so seems happy that he trust it. Its quite possible that the component author simply didn't think ahead enough to supply source or strong name the component. The only person in a position to assess the level of risk involved and whether there are licensing issues involved is the OP who I assume, if there had been some kind of license attached would have D/L'd it at the same time as the component and so will be able to check that issue out.

I would absolutely recommend him reverse engineering into a language of his choice and verifying the code doesn't do anything malicious as he has no way it would seem of contacting the author.But he's still in a position of having a component he cannot use unless he finds some way to strong name this component. Of course, hopfully, it may well happen that after verifying the code himself that he is then in a position to create a similar component himself without having to resort to reverse engineering.

Regards

Richard Blewett - DevelopMentor
http://staff.develop.com/richardb/weblog

If the source isn't distributed with a component, chances are pretty good
that its license might prohibit reverse engineering and decompilation.
Also, unless one performs a thorough code review, recompiling the component
won't do much to resolve the underlying problem which, IMO, remains one of
whether one can trust the code enough to use it.
 
Well, yes the question was misread indeed but it is a good idea IMHO. As for
"my" problem I agree with Mr. Blewet that I am the only one that can -and
should- assess the authenticity of this assembly. Good thing is... I
recently found out the assembly does have a strong name, it is signed so one
thing out of the way.

Nevertheless it brings up the point of using third-party unsigned assemblies
during development. Yes, sure there are security issues to asses but that is
ultimately left to the developer, only you may be stuck sometimes with the
strong name thing and have to either reinvent the wheel or buy an expensive
component. Will keep an eye on that.

Thx,
E.
 
Back
Top