Deploying strong-named app

[NormD]

Our application has three strong-named keys that have to be set up on the
local machines. Apparently the Framework can be pushed to the clients with
SMS, but I'm being told a human has to do things on the PCs to get handle the
keys.

Can it be automated? Is it feasible to have a link on a Web page a new user
could go to to get not just the Framework but these keys installed?

[Kevin Yu [MSFT]]

Hi,

Do you mean you need to deploy the key or strong-named assemblies? Because
spreading the key is not secure. Anyone who gets the key can use the key to
sign their assembly. Also, we don't need to deploy keys when using an
application.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[NormD]

We have several packages we use that are strong-named by their suppliers. In
order for someone to use these their .NET config apparently has to be "told"
the keys. We have run the config utility and it'll make an MSI, but then the
"target" machine gets all the settings from the source machine, not just the
ones we want to distribute; there is no option (I'm told) forgetting just
certain ones (ours). I understand what you're saying about the keys, but
that's the mechanism the vendors use to control their code; I think tthe keys
are "branded" for our implementations so you can't use them with another copy
of the vendor's code.

Suggestions?

"Kevin Yu [MSFT]" wrote:

Hi,

Do you mean you need to deploy the key or strong-named assemblies? Because
spreading the key is not secure. Anyone who gets the key can use the key to
sign their assembly. Also, we don't need to deploy keys when using an
application.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Richard Grimes]

NormD wrote:

We have several packages we use that are strong-named by their
suppliers.
Are you suggesting that the assemblies are signed so that they have a
striong name?
In order for someone to use these their .NET config
apparently has to be "told" the keys.
If the assmblies have a strong name you do *not* need to have access to
the keys. When you compile your assembly that uses one of those signed
assemblies the compiler extracts enough information (specifically, it
gets the publickeytoken derived from the public key in the signed
assembly) and places this in the resultant file.

Work through my Fusion workshop and you'll see what the keys are used
for.
ones (ours). I understand what you're saying about the keys, but
that's the mechanism the vendors use to control their code; I think
tthe keys are "branded" for our implementations so you can't use them
with another copy of the vendor's code.

The other thing that you might mean (your description is a little
confusing) is if the vendor assemblies have licenced controls and they
require some software key to be installed before the control will work
at runtime. If that is the case then it is not associated with the
strong name mechanism.

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm

[Kevin Yu [MSFT]]

Hi,

Yes, I agree with Richard, that the strong named assemblies contains their
own information on key(public key token). If the deployment requires
ditribute the key from the vendor, it's not the strong name key. In this
case, I suggest you try to post in the microsoft.public.sms.admin newsgroup
for more information on how to distribute the keys.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[NormD]

I hope you'll both look at this and tell me if you think I should still post
this where you suggested, Kevin.

My explaination of the situation is confusing because I know just enough to
be dangerous. People are explaining it to me and I don't know that they're
using the right words. Now I know more information.

As you suggested it is not the strong keys that are needed; they're compiled
into the code. Apparently we're using three components, and the securitiy
policy (machine level usually) needs to be set with the "public key." Or is
this more correctly called the GUID? Anyway, from the MS Security Policy
config tool one can either point to the dlls or with the poliicy setting tool
put in the "keys" (which we supply them). Having to do this manual process
on each machine is not nice!

We'd like to be able to automate this process to it can be pushed out to
clients (SMS?) or otherwise made as easy as possible for administrators.

We did create an MSI script from one machine and ran it on another, and this
did the job! The bad news is it blows away other secccurity policeis on the
target machine! Not good! Is there a way to have the MSI do just "our"
changes?

Hope this makes more sense than what I previously wrote. Thaks for your
help, guys.

"Kevin Yu [MSFT]" wrote:

Hi,

Yes, I agree with Richard, that the strong named assemblies contains their
own information on key(public key token). If the deployment requires
ditribute the key from the vendor, it's not the strong name key. In this
case, I suggest you try to post in the microsoft.public.sms.admin newsgroup
for more information on how to distribute the keys.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."

[Kevin Yu [MSFT]]

Hi,

From your description, it seems the key you mentioned is not the strong
named key in .net assembly. They are different concepts. I'm not quite
familiar with how to deploy these keys with MSI scripts. Please try to ask
in the newsgroup I have suggested for SMS issue. Also, for MSI scripts, you
can also post in the following newsgroup.

microsoft.public.windows.msi

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."