問題タブ [strong-named-key]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
1 に答える
989 参照

c# - 署名付きの DLL を署名なしの DLL に置き換えるとどうなりますか?

厳密な名前が付けられ、GAC に配置された多数のライブラリがあります。私たちは慣習から離れようとしています。これが、現時点で対処する必要があるシナリオです。

キーを再現できないため、適切に署名または厳密な名前を付けることができない DLL (既存のものと署名済みのもの、同じ名前と全体的な構造を置き換える) があります。署名されていないバージョンを使用してコンポーネント/コードを再コンパイルし、後で . 署名されたコピーを GAC から削除した場合、他のコンポーネント (同じプローブを使用する) は、再コンパイルせずに新しいコンポーネントを消費しますか、それとも署名されたバージョンを要求しますか?

ありがとうございました。

0 投票する
1 に答える
177 参照

c# - 署名済みアセンブリ チェーンの遅延

私は C# .NET アセンブリ (名前: A.exe) を開発しています。このアセンブリは遅延署名してから、サード パーティの会社によって完全に署名される必要があります。署名を遅らせるために、公開鍵を使用します。アセンブリ A は、共通ライブラリの一部であるアセンブリ B.Core.dll、B.Common.dll、B.Logging.dll を参照します。B アセンブリは遅延署名されていないため、ildasm/ilasm を使用して分解し、遅延署名付きで再組み立てします。A.exe と B.Core.dll、B.Common.dll、B.Logging.dll を送信しましたが、これらは完全に署名されていますが、A を起動すると次のエラーが表示されます:

ファイルまたはアセンブリを読み込めませんでした 'Assembly B1 PublicKeyToken= A.exe

は遅延署名されたアセンブリ (Strong Name プロパティが True に設定されている) を参照しているため、この問題は A.exe に関連するものではありませんが、原因は B.Core にあると思われます。
実際、B.Core は B.Common と B.Logging を参照しますが、B.Common と B.Logging は互​​いに独立しています。
エラーの原因は、B.Core が最初に署名されていない B.Common アセンブリを使用してビルドされ、その後、3 つのアセンブリすべてを逆アセンブルして再アセンブルし、参照が変更されなかったことである可能性があります... 問題を解決するために、私が行ったことA のビルド後の手順として、4 つのアセンブリすべてを 1 つの遅延署名付きアセンブリにマージすることを考えています。うまくいくと思いますか?
B.Core は .NET MEF を使用して、A からエクスポートされたインターフェイスを動的にロードすることに注意してください。このプロセスに問題はありますか?

よろしくお願いいたします。

0 投票する
4 に答える
673 参照

obfuscation - 誰かが管理されたアセンブリをロードできないようにする最も簡単な方法は?

ここで.Netセキュリティ初心者...他の誰かが私のアセンブリをロードするのを防ぐ最も簡単な方法は何ですか?

背景: 私は本当に「十分な」保護 (誰かがクラック、ハッキング、攻撃に成功するのに十分な時間/お金/賢さ) を探していますが、これはすでに解決された問題のように思えます。

これが私が知っている(と思う)ことです:

  1. 厳密な名前付けはセキュリティ層として使用できますが、このマイクロソフトのドキュメントによると、必ずしもそうすることが意図されたわけではありません(「警告: セキュリティのために厳密な名前に依存しないでください。一意の ID のみを提供します。」を参照してください)。

    その上で、サードパーティのアセンブリをロードできなかった状況に遭遇したことに注意してください (そうであったと思います)。そのため、ライブラリを使用するために、アセンブリをildasmし、独自のsnkで署名してから、ilasmを戻す必要がありました。そのため、厳密な名前付けは、私にとって優れたセキュリティ メカニズムとは思えません。 ただし、呼び出し元のアセンブリが自分の公開キー トークンで署名されていることを確認するコードでの簡単なチェックはどうでしょうか。これは十分に効果的ですか?

  2. 私が達成しようとしていることに厳密な命名を使用すべきではない場合、dll に Authenticode デジタル署名チェックを実装する方が良いルートですか (wintrust.dll がこれに役立つようです)?

    私は難読化のためにいくつかのベンダーのツールを試してきましたが、多くのベンダーにはライセンスやあらゆる種類のものが付いています。機密性の高い部分を隠すために少しの難読化を使用する可能性がありますが、多くの場合パフォーマンスを伴う文字列やコードの暗号化などの機能を使用せずに、誰かが機密性の高いライブラリをロードできないようにするメカニズムが必要です。 (およびその他の) コスト。

質問に戻りますが、誰かが私のアセンブリをロードするのを防ぐ最も簡単な方法は何ですか?

0 投票する
0 に答える
733 参照

visual-studio - エラー MSB3325: 次のキー ファイルをインポートできません。再起動の問題

キー ペアをキー コンテナーにインストールしました。その後、ビルドできます。コンピューターを再起動すると、エラーが再び発生します。

解決策は、少なくともコンピューターを再起動するまでは、管理コマンド プロンプトを開いて次のコマンドを入力することです。

最初のコマンドは既存のキーを必要に応じて削除し、2 行目はキーを追加します。パスワードの入力を求められます。その後、ソリューションが構築されます。

VS2017でも同じ問題があったため、Visual Studioのバージョンに違いはありません。

考え?