アセンブリに署名するには、Aで使用されているすべてのアセンブリB、C、Dが署名されていることを確認してから、B、C、Dなどで使用されるすべてのアセンブリを確認する必要があります。私はこれのセキュリティ上の利点は何か分かりません。私はそれが改ざんを防ぐと思われるが、アセンブリAは任意のファイルを開くことが許可され、これらは改ざんされる可能性があります。同じことが外部ウェブサーバーにも当てはまります。強く命名されたアセンブリは、署名されていないアセンブリを使用できないのはなぜですか？
また、パブリックにして要件を回避する.snkファイルでアセンブリに署名するのは簡単すぎます。
強力な名前付けのもう一つの理由はバージョン管理です。強力な名前のアセンブリを参照すると、その特定のバージョンが取得され、依存する特定のバージョンで依存関係が読み込まれます。
EDIT
シナリオ例：あなたがGACにアセンブリを入れた場合は、サイド・バイ・サイドバージョン管理を可能にするために名付け強くなければなりません。しかし、依存関係もそこになければ、GACに入れることはできませんでした（そうでなければ、実行時にロードできません）。これらのアセンブリが確実にロードされるためには、GACでも強く命名されている必要があります。
はい。私は強い命名に利点があることに同意します。私が見ていないことは、推移性要件の恩恵です。 –
厳密な名前のアセンブリは信頼できることを意味し、与えられたセキュリティのレベルは、コードが正当なソースからのものであるという考えに基づいているからです。つまり、相互作用する他のすべてのアイテムは、同じセキュリティコンテキストで実行されるため、信頼される必要があります。
厳密な名前のオブジェクトがこのように動作しなかった場合、攻撃の方法は、署名されていないアイテムを攻撃者が実行したい不正なコードに置き換えることです。不正なコードは、署名されたアイテムの信頼できるセキュリティコンテキストで実行されます。
通常のファイルアセンブリAを上書きしたり、接続している偽のWebサーバーを上書きすることができます。おそらくAはこれらのソースからランタイムコードを作成し、セキュリティ上のリスクは同じです。 署名されていないアセンブリを使用して攻撃を開始するのはAの呼び出しです。 Aはすでにこれを行うことができます。鍵でBに署名して公開するだけです。それはちょうど不便です。 –
そうでなければ、アセンブリB/C/Dを別の（ハッキングされた）ものに置き換えることができます。それらをロードしてコードを実行します。強力な命名では、ハッキングされたB/C/Dに同じ鍵で再署名することも、ハッキングすることもできません。
署名されていればB/C/Dを置き換えることはできません。それはAの呼び出しです。 –
@ブリュノ - それは私の主張である... –
しかし、それは今どのように動作しません。 Aは、符号付きまたは符号なしのB/C/Dに依存するかどうかを決定できません。彼らはAがだから署名されなければならない。 –
".snkファイルでアセンブリに署名するのは簡単すぎますあなたのsnkファイルをパブリックにしないでください... –
私は推移性要件の回避策としてそれを意味しました。私のポイントは、それが十分に簡単ではないということです。過渡的要件を持たないことはより簡単で同じことになります。 –
Eric Lippertさんが最近このブログについてブログしました：http://blogs.msdn.com/ericlippert/archive/2009/06/04/alas-smith-and-jones.aspx –