Why not make all assemblies as Strong Named Assemblies

[Guest]

If strong-named assemblies have so many advantages, why not sign all
assemblies with strong-name. Is there any scenario, where an assembly should
not be signed with strong-name?

 

[Joyjit Mukherjee]

Hi,

typically, an assembly that is consumed only by the appliation for which it
is created, is a candidate for a private assembly. So, it doesn't requires
strong name signing as only the application that created it uses its
functionality.

HTH
Regards
Joyjit

 

[Richard Blewett [DevelopMentor]]

The advantages that strong named assemblies have:

1) The assembly name has uniqueness and so it can be deployed outside of the AppBase

2) The Assembly Loader can detect tampering with the assembly

3) Versioning now is taken notice of

1) and 2) are only reliable if you have a process for key management. Most specifically if your proiate key becomes known then kiss goodbye to the guarantee of 2) and partially of 1), someone can spoof your assembly with their own and change your assembly and re-sign it. I say partially for 1) because if you are only interested in preventing *accidental* collision of assembly names then private key management isn't an issue.

Point 3) may actually be a problem rather than a benefit. You cannot pass types from one version of an assembly in place of types from another version - if this is a scenario you think may occur with your application (more than one version of it loaded into an AppDomain and types used from one version where another is expected) then you may really prefer the CLR to igmore the version. One wau round this is to keep your version number the same on your assembly, but then how do you tell which version of an assembly soneome is using? If You don't strong name then unless the applkication uses Assembly.LoadFrom it will always pick up a single version.

The other issue with strong named assemblies is that, by default, they cannot be called from partially trusted code. To allow this you have to apply the [AllowPartiallyTrustedCallers] attribute to your assembly and this should never be done lightly. Its possible to open up gaping security holes by mistake this way.

So for no-touch deployment applications (which often run in a partially trusted environment) strong naming can be an problem not a benefit.

Regards

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

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

If strong-named assemblies have so many advantages, why not sign all
assemblies with strong-name. Is there any scenario, where an assembly should
not be signed with strong-name?

---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.framework]

 

[Patrick Philippot]

Hi Richard,

1) and 2) are only reliable if you have a process for key management.
Most specifically if your proiate key becomes known then kiss goodbye
to the guarantee of 2) and partially of 1),

Obvious. But this applies to any authentication process. If you leave
the keys of your front door hanging on the outside of your door, anyone
can enter your house. So producing key pairs for any authentication
process *implies* having a process for key management as well. This is
not new and not specific to .Net. The same applies to digital
certificates used to authenticate ActiveX Controls for example.

 

[Richard Blewett [DevelopMentor]]

You may say its obvious but you'd be surprised at how many dev shops don't realise the impact of strong naming on their processes. You will find the public/private key pair in their version control system or no strategy for hotfixing with delay signing, etc. Agreed its not a new problem, but its one that isn't always apparent to people who simply are trying to find out how they gtet their component in the GAC.

Regards

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

nntp://news.microsoft.com/microsoft.public.dotnet.framework/<[email protected]>

Hi Richard,

1) and 2) are only reliable if you have a process for key management.
Most specifically if your proiate key becomes known then kiss goodbye
to the guarantee of 2) and partially of 1),

Obvious. But this applies to any authentication process. If you leave
the keys of your front door hanging on the outside of your door, anyone
can enter your house. So producing key pairs for any authentication
process *implies* having a process for key management as well. This is
not new and not specific to .Net. The same applies to digital
certificates used to authenticate ActiveX Controls for example.

--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr



---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.766 / Virus Database: 513 - Release Date: 17/09/2004



[microsoft.public.dotnet.framework]

 

[Eduard Ralph]

If strong-named assemblies have so many advantages, why not sign all
assemblies with strong-name. Is there any scenario, where an assembly should
not be signed with strong-name?

why bother with the effort unless you really need it? You have to make
a key, keep track of it and set it up in the attributes....

Eduard Ralph

 

[Guest]

We automated the effort to sign the assembly with the strong-name (using
macros in VS.NET) So, that is not a problem. And also, our private keys are
well protected (we treat them as one of our infrasture resources.)

We initially deployed assemblies as private assemblies, but later some other
business processes started using them. Thus, we end up rebuilding (and
redeploying) the assemblies with the strong-name.

Therefore, my logical design decision would be - no harm in signing ALL .Net
assemblies with the strong name. Thank you, Richard, I will watch out for
AllowPartiallyTrustedCallers

Thanks, SriniK

 

[Cowboy \(Gregory A. Beamer\)]

The pros do not always outweigh the cons. Depending on the trust domain, you
can end up with code that no longer runs. In addition, you can end up with
versioning issues on an app and have to recompile additional software when
you recompile a referenced assembly. Both of these are headaches for apps
that do not get any benefit from strong naming.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

*************************************************
Think outside the box!
*************************************************

 

[Jonathan Allen]

Still, why bother if you don't need it? I've never used a signed assembly
and thus never had to worry about protecting the private key.