問題タブ [strongname]

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 投票する
2 に答える
1160 参照

.net - 再コンパイルせずに、アセンブリを厳密な名前のアセンブリに変換できますか?

Microsoft KBの記事を見つけました:

しかし、私がキーペアを作成した後、彼らは私に再コンパイルを求めているようです。再コンパイルせずに、アセンブリを強力な名前付きアセンブリに変換する方法はありますか?

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

.net - リフレクションを使用して、署名されたアセンブリから署名されていないアセンブリにタイプをロードできるのはなぜですか?

私は2つのアセンブリAとBを持っています。Aは強い名前が付けられていますが、Bはそうではありません。

MSDNによると、強い名前のアセンブリは別の強い名前のアセンブリしか参照できないため、AからBを参照することはできません。

しかし、なぜアセンブリBをロードし、そのクラスをインスタンス化し、リフレクションを使用してアセンブリAからメソッドを呼び出すことができるのでしょうか。

これは、署名されたアセンブリで署名されていないアセンブリを参照できないようにするという目的そのものを打ち負かしませんか?

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

.net - .NET:強力なネーミングとAuthenticode

たとえば、ここで.NETの厳密な名前について読んだことがあるので、次の質問があります。

すべてのEXE、DLL、およびMSIファイルに署名するAuthenticodeコード署名証明書があります。その利点は、MSIが信頼できるソースからのものであることをWindowsが認識していることと、必要に応じて各ファイルの信頼性を検証できることです。

現在、 .NETの厳密な名前は使用していません。ファイルに厳密な名前を付けるということは、本質的に、自己署名証明書でデジタル署名されていることを意味することを読みました。これについての私の意見は、信頼できる認証局によって署名されたAuthenticode証明書は、ルート証明書がないために誰も真正性を確認できない自己署名証明書よりもはるかに価値があるということです(エンドユーザーに配布するつもりはありませんが、私たちは!?)。

質問: Authenticode署名がすでに使用されている場合、追加の厳密な名前付けアセンブリに価値はありますか?

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

c# - ユーザー アプリが変更されるたびに、アセンブリを GAC に再デプロイする必要がある


したがって、基本的には、コンポーネントの 1 つである App.exe によって使用される厳密な名前 (厳密に署名された) アセンブリ x.dll があります。アセンブリの署名キーはリポジトリにあり、アセンブリは書き込みによって署名されています

アセンブリは、共通パッケージをインストールするインストーラーによって GAC に配置されることになっています。common.msi という名前にしましょう。ただし、コンポーネント自体は App.msi によってインストールされます。一緒に展開すると、すべてが機能します。しかし、x.dll とはまったく関係のない変更が App.msi に加えられ、App.msi が再展開されると、App.exe は x.dll を見つけられません。x.dll は変更されないことに注意してください。ただし、common.msi も展開すると、すべてが機能します。だから私は、ビルドバージョンか何か、または私が何も知らないマニフェストに問題があるに違いないと推測しています。私が間違っていることは明らかですか?アセンブリを個別に展開し、変更されない限り触れず、それを使用するコンポーネントが変更されるたびに再展開することはできませんか? ありがとう。

編集:ssemblyをGACに入れることは要件です(私には何もできません)

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

managed-c++ - snkファイル使用時のマネージC++エラー::「署名に必要な秘密鍵がありません」

.snkファイルを使用してマネージC++プロジェクトに署名しようとすると、このエラーが発生するのはなぜですか。「......SlimDX\ build \ vs2010 \ x86 \ Debug \VOS.snk'に署名に必要な秘密鍵がありません」

プロジェクト設定で設定してみました::

  1. キーファイル=$(ProjectDir)x86 \ $(Configuration)\ VOS.snk
  2. 遅延記号=いいえ(/ DELAYSIGN:NO)

そして、iv'eはAssemblyInfo.cppで設定しようとしました::

  1. [アセンブリ:AssemblyKeyFile( "VOS.snk")]
  2. [アセンブリ:AssemblyDelaySignAttribute(false)]

.snkファイルと.pfxファイルの両方があります。ここで何が欠けていますか?.snkファイルはC#.NET3.5プロジェクトで必要なすべてです...マネージC++プロジェクトでも機能しないのはなぜですか?何らかの方法でpfxファイルを使用する必要がありますか?

0 投票する
3 に答える
1204 参照

.net - プロジェクトソースと一緒に.snkファイルを出荷する理由はありますか?

時々、強い名前でコンパイル結果に署名するために使用される.snkファイルを含むサンプルプロジェクトがネットワーク上に表示されます。

ちなみに、これは明らかに間違っています。.snkファイルが公開されると、元のコードサプライヤから出荷されたが、現在は悪意のあるコードが含まれているアセンブリを置き換えるために使用できるアセンブリを誰でも作成できます。.snkファイルを出荷する人は、そのリスクを真剣に扱っておらず、ファイルを出荷するだけだと思います。そうしないと、プロジェクトが既成でコンパイルされないためです。

「便利」以外に.snkファイルを発送する理由はありますか?

0 投票する
2 に答える
2299 参照

.net - 厳密な名前で署名すると、一連のアセンブリの偽造をどのように防ぐことができますか?

厳密な名前 (.snk ファイルに格納されたキーペア) による署名は、(他の用途の中でも)アセンブリの偽造から保護することを目的としています。

例: 厳密な名前で署名されたアセンブリを出荷した後、他の開発者が私のアセンブリを使用したため、そのアセンブリには私のキーペアの公開キーに言及している私のアセンブリへの参照が含まれています。一部のユーザーは、その開発者アセンブリと私のアセンブリをインストールし、その開発者のコ​​ードを喜んで使用します。他の誰かが私のバージョンのように見えるアセンブリを作成しようとし、それが「インストールする価値のある更新」であることをユーザーに納得させた場合、私は自分のキーペアを制御しており、偽造されたアセンブリは同じキーペアで署名されていないため、偽造されたアセンブリは読み込まれません。 . わかりました。

しかし、悪意のある当事者が私のアセンブリと他の開発者の依存アセンブリの両方を偽造し、それらの両方を「出荷」することを防ぐのは何ですか? 彼らは私のアセンブリとその開発者のアセンブリを取得し、両方を改ざんし、私のアセンブリの偽造バージョンに任意のキーで署名し、それへの参照を依存アセンブリの偽造バージョンに追加し、署名してから両方を出荷します。つまり、悪意を持って 2 つのアセンブリを「出荷」することは、1 つのアセンブリを「出荷」するよりもはるかに難しくないはずです。

厳密な名前で署名すると、複数のアセンブリの偽造からどのように保護されますか?

0 投票する
3 に答える
712 参照

asp.net - ASP.NET 2.0 の bin フォルダー内の厳密な名前のアセンブリ

ASP.NET の初期のバージョンでは、厳密な名前のアセンブリを bin フォルダーに配置しないことを知っています。これが問題を引き起こしたことは覚えていますが、具体的にどのような問題があったかは覚えていません。これが ASP.NET 2.0 にも適用されるかどうかは誰にもわかりませんか? ASP.NET 2.0 以降のバージョンで、厳密な名前のアセンブリを bin フォルダーに配置しない理由はありますか?

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

c# - 動的に生成されたアセンブリ用の InternalsVisibleTo ですが、厳密な名前が付けられています

動的コード生成を使用してプロキシ クラスを作成するプロジェクトがあります。このプロキシ クラスはプロジェクトの内部クラスを使用するため (実装の詳細が公開されないようにするため)、動的に生成されたアセンブリの名前で InternalsVisibleTo を使用します。私のクライアントが出荷されたすべてのアセンブリに厳密な名前を付けるという要件を課した最近まで、これはうまく機能していました。

この問題が発生するのは、厳密な名前のアセンブリで InternalsVisibleTo を使用するには、それが参照するアセンブリも厳密な名前である必要があり、公開キーを提供する必要があるためです。私が立ち往生しているのは、動的に生成されたアセンブリに厳密な名前を付ける方法です。これが私がこれまでに行ったことです:

  1. .snk を製品と共に出荷できるように、動的アセンブリ用の新しいキー ペアを作成しました (明らかに、プロジェクト アセンブリの残りの署名に使用される .snk を出荷したくありません)。
  2. PublicKey を抽出し、動的に参照されるアセンブリに新しい動的 PublicKey を使用するように InternalsVisibleTo を更新しました。
  3. 次のように、動的に生成されたアセンブリに署名しようとしました。

    /li>

残念ながら、これは機能しておらず、これがどのように機能するかについてのドキュメントを見つけるのに非常に苦労しています。InternalsVisibleTo 経由でアクセスできるように、動的に生成されたアセンブリに署名する方法を知っている人はいますか? 必要なクラスを公開することはできますが、カプセル化したままにしておくほうがよい実装の詳細が漏れてしまいます。

0 投票する
2 に答える
1138 参照

c# - ASP.NET Web サイト内の厳密な名前の DLL を更新して、新しいバージョンの遅延署名付き DLL を使用するにはどうすればよいですか?

LinkedInToolkitのデバッグでは、git からDotNetOpenAuth ソースをダウンロードしました。参照を追加したので、LinkedInToolkit から取得した事前構築済みの Web サイトをコンパイルすると、次のエラーが発生します。

ファイルまたはアセンブリの DotNetOpenAuth バージョン 3.4.7.11039 を読み込めませんでした。厳密な名前の署名を変更できませんでした....

DotNetOpenAuth DLL が遅延署名されていることを考慮して、Web サイトをコンパイルして実行するにはどうすればよいですか?

厳密な名前の DLL についての言及がないか、web.config と参照を検索しました。厳密な名前のチェックは他にどこで行われますか?