2

オープンソースのクラスライブラリをリリースしたいとします。snkを一緒に公開するべきかどうか疑問に思っています。たとえば、snkでdllをGAC対応にする必要があります。パブリックsnk(NHibernate)と非公開プロジェクト(DevExpress)の大きなプロジェクトと、両側からの小さなプロジェクトを見たことがあります。したがって、一般的な合意はありません。確かにそうです。

秘密鍵を公開していないとしましょう。開発者自身であるこのライブラリのユーザーは、変更を加える場合はソースを再コンパイルするか、厳密な名前の検証の例外を作成する必要があります。両方の首の痛み、私はそこに行ったことがあります。

公開したとしましょう。私はそれがどのように悪用されるのか見当がつかない。CASなどはもう広く使用されていません。さらに、.NET4.5では非推奨になっています。したがって、貧しいユーザーが公開鍵トークンに基づいて私のアセンブリにいくつかの権限を付与し、悪者が同じトークンを使用して不正なアセンブリを作成するのとは異なります。悪者が自分のdllを誰かのコンピュータに置くことができれば、それは彼らを止めることになる強い名前ではありません。

アセンブリの公開鍵トークンをチェックする人はいないと思います。確かに、ランタイムは、参照するアセンブリがコンパイルされてから変更されていないことを確認しますが、それだけです。出版社はトークンを公開しないので、私が知っている限りでは、私がコンパイルするときに、最初にファウルアセンブリを参照することがあります。

だから私はsnkを公開することに傾いています。理論的にはセキュリティがほとんど提供されておらず、実際にはセキュリティが提供されていないように見えます。それで、なぜユーザーの生活を困難にするのでしょうか。そして多分私はX.509コード署名(本当に秘密の秘密鍵を持つもの)をするべきです、しかし私はほとんどの人がとにかくそれをチェックしないと思います。

公開するかしないか?最良の議論が勝ちます。理論的側面、実用的側面、MS™ガイドライン、すべて歓迎します。

4

2 に答える 2

4

私はそれを公開しません。

攻撃者は、悪意のあるコードを追加してアセンブリを再コンパイルできます。変更されたアセンブリには、あなたと同じ強い名前が付けられます。

キーを公開しない場合は、ライブラリの「信頼できる」バイナリとキーなしのソースコードを配布できます。サードパーティの開発者がライブラリをカスタマイズする必要がある場合は、ライブラリの新しいキーを生成するだけです(ただし、結果のアセンブリには公式バージョンとは異なる厳密な名前が付けられ、ランタイムが2つを区別できるようになります)。

于 2012-05-28T16:01:50.470 に答える
1

強力な名前付けキーを配布するべきではありませんが、それはセキュリティとはほとんど関係がありません。

厳密な命名は識別手法であり、セキュリティ対策ではありません。これは、偶発的なアセンブリIDの衝突を防ぐことのみを目的としています。(「深刻な」セキュリティの使用に十分な強度を持たせるには、自己生成キーではなく、取り消し可能なキーが必要になります。)

ただし、偶発的な衝突を防ぐことは、オープンソースプロジェクトで署名キーを配布しない十分な理由です。これが、バージョン1.2.3.4が他の誰かによって変更されたソースからコンパイルされたバージョン1.2.3.4と同一に見えるのを防ぐ主な理由です。プロジェクトのソースコードを公開する主な目的の1つは、通常、変更されたコードからコンパイルされたアセンブリを配布できるようにすることであるため、オープンソースプロジェクトでは、適切に個別化された厳密な命名が重要であると主張することもあります。クローズドソース配布。

于 2012-06-04T13:39:22.010 に答える