.NETアセンブリに署名しないことで何か問題はありますか？

私の同僚の1人は、アセンブリの署名に非常に熱心です。彼は文字通り何かに署名しようとします。署名されていないMicrosoftのアセンブリを使用する場合でも、彼はソースコードを取得して署名し、他の開発者にコピーを使用するよう依頼します。

アセンブリへの署名の背後にある基本的な考え方を理解できます。特定のアセンブリが危険なハッカーによって侵害されないようにするためです。したがって、ソフトウェア開発会社の場合、.NETライブラリを顧客にリリースする前にアセンブリに署名する必要があります。

ただし、ここでは主に自分用のWebアプリケーションを開発しているため、使用するすべてのアセンブリに署名する意味がわかりません。

ここで何か不足していますか？

信頼された環境内で使用されるアセンブリに署名することは、私にはやり過ぎに聞こえます。

署名されたアセンブリの興味深い点は、暗号化された検証が必要なため、署名されていないアセンブリよりも読み込みが少し遅いことです。

アセンブリに署名するには、依存するすべてのアセンブリにも署名する必要があります。私の推測では、これは同僚がすべてに署名したいという願望に貢献していると思います-コンパイラーはそれを要求しています。

編集この回答を書いてから、プロキャンプと反対キャンプの両方でほぼ同等のサポートがあることがわかります。ここに正しい答えがないのは明らかです。

ただし、この編集を強制したのは、現在、NuGetから非常に多くのオープンソースライブラリを取得しており、それらの多くはまったく署名されていないということです。アセンブリに署名したい場合は、依存関係も署名する必要があります。署名されたオープンソースライブラリの多くには、署名に使用される秘密鍵がソースリポジトリで公開されており、利用できます。

すべての場合と同様に、行うべきトレードオフがあります。（として、または学術プライベート環境で作業の私の経験では、署名の利点は、主に理論的です@ user289100が言及）あなたはのように多くのレベルについて偏執的である必要があり、その場合、あなたのコードを変更する政府機関を懸念している場合を除き、署名するインフラストラクチャは少しの労力のように思えます。それ以外の場合、すべてに署名する必要があることからカスケードされる課題の量は、それだけの価値があるとは思えません。ただし、環境によって要件が異なる場合や、マゾヒストになる場合があります。

厳密な名前を使用する場合のアセンブリのバージョン管理に関連する課題については、Teun Dの回答も参照してください。

私は、署名されていないアセンブリを利用して、以前に問題を回避し、それが重要である理由を人々に示しました。署名されていない（再びアカデミック設定で）DLLファイルを同じ名前、同じ署名で作成したDLLファイルに置き換え、.NET Reflectorを使用して元のコードをコピーして貼り付けましたが、私のメールではユーザー名とパスワードをメールで送信しました「実際の」コードを呼び出す前に渡されていました。

署名されている場合は、署名を一致させることができますが、置き換えることはできません。Zippyの言うこととは逆に、実行時のコンパイルエラーが発生します。

アセンブリへの署名は決してやり過ぎではありません。30秒かかります。田舎に住んでいるなら、ドアをロックするのはやり過ぎだと言っているようなものです。持ち物を賭けたい場合は、開いたままにしておきます。攻撃を受けるのに必要なセキュリティ違反は1つだけです。アセンブリに署名するのに30秒しかかかりませんし、ビジネスケースがないわけではありません。パフォーマンスへの影響はごくわずかです。

もう1つのポイント：アセンブリに署名すると、バージョン間の下位互換性が失われます。すべての参照にはバージョン番号が含まれ始め、他のバージョン番号を持つバージョンは非互換と見なされます。これは、分散アセンブリの新しいバージョンへのアップグレードを妨げます。

私の意見では、アセンブリにコード署名する必要があるのは、アセンブリから具体的なメリットが得られる場合のみです。

• 信頼できない人がアセンブリに触れる可能性がある環境に展開する場合
• 信頼をアップグレードするための証拠として証明書を使用する特定のプラグインモデル
• コードが他の署名されたコードから呼び出せるようにする必要がある場合（log4netなどのプロジェクトは、正当にコードに広く使用できるように署名します。数年前に秘密鍵を失うことにより、互換性が大幅に損なわれ、コード署名のもう1つのリスク） 。
• GACにデプロイする場合

あなたの同僚は、なぜ彼が議会に署名するのが好きなのかについて何か指示を与えましたか？ここではまだ説明されていない署名の利点の1つは、署名されたアセンブリのみをGACに配置できる（つまり、管理されたプロセス間で共有できる）ことですが、私の（確かに経験の浅い）観点からは、マイナス面がプラス面を上回るようです。

自己署名のMicrosoftコードに関する逸話は、特に疑わしいようです。MSがコードに署名しなかった場合、おそらく理由がありますよね？そしてそれに署名することで、あなたがそれを書いていないときに責任を負うことになります-将来があなたを噛むもう一つの機会です。

アセンブリへの署名に関するもう1つのことは、アセンブリの代わりに誤ったアセンブリを注入できないことです（偶然にも自分で）。たとえば、アセンブリFoo.dll、バージョン1.0を参照するプログラムを作成した場合、誰かが同じバージョンのアセンブリを作成し、自分のライブラリを置き換えることができます。ライブラリに署名すると、（少なくとも私はそれが簡単に可能だとは思いません）。

署名は、アセンブリがGACに配置されている場合にのみ必要です。署名されたアセンブリは、誰かがそれらを台無しにすることを妨げません。ハッカーはまだ署名と署名をチェックするその他のコードを取り除くことができます。

少しもったいないようだ。ファイルが意図したとおりであること（そして改ざんされていないこと）を確認するために本当に必要です。ただし、独自のネットワークセキュリティとWebサーバーの範囲を信頼している場合、Webアセンブリへの署名は冗長な手順のように思えます。

しかし、多分それは私の中小企業の話です。ミッションクリティカルなオンラインバンキングWebサイトについて話している場合は、サインアウトしてください。

何かを発送する予定がある場合や、実際に発送する理由がある場合は、それを検討してください。それ以外の場合は、面倒です。彼が実際にこれを行うことから何を得るかあなたの同僚に尋ねます

私は以前に署名されたアセンブリに遭遇したことがあり、特にアセンブリの署名についての知識がほとんどない、またはまったくない人々の数、それが何のために、どのようにそれを行うかを考えると、それは後面の痛みです。どうしても必要な場合以外は、気にする必要のないもう1つのことです。

deploy-from-the-web ClickOnce XBAPで使用する場合は、アセンブリに署名する必要があります。

さらに、参照されるすべてのアセンブリにも署名する必要があります。

次のようなエラーが発生する場合があるため、アセンブリに署名します（これはテストによるものですが、アプリケーションの実行時に発生する可能性があります）。

System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

TearDown : System.IO.FileLoadException : Could not load file or assembly 'Latitude.Platform.Core, Version=1.0.5871.22518, Culture=neutral, PublicKeyToken=7926214d13e12325' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Visual Studioが時々間違って古いコードを実行することがわかりました。

古いコードを実行しているときにエラーが必要な場合は、アセンブリに署名します。

nugetパッケージを作成している場合は、アセンブリに署名してください。署名されていないアセンブリは、最新バージョンのコードを実行していることを確認したい私たちにとっては厄介です。 Visual Studioを修正できません。私ができることは、Visual Studioが間違っていることを検出することだけです。だから、あなたのnugetアセンブリに署名してください。