JARファイルに署名する必要があるのはなぜですか？
JARファイルに署名する必要があるのはなぜですか？
クライアント側のJARファイル（アプレットを含む）に署名して、ファイルシステムアクセスなどの特別なことを実行できるようにし、ウィンドウの下部にある煩わしいビットが表示されないようにする必要があることはわかっていますが、それ以外の理由は何ですか？また、サーブレットなどを含むサーバー側のJARファイルに署名する必要がありますか？
JARに署名する時期と時期に関するいくつかの基本的なルールをいただければ幸いです。ありがとうございます。
簡単な答え-あなたの会社の方針があなたに強制しない限り、しないでください。
長い答え
jarに署名することは、「これを作成しました。システムを混乱させないことを保証します。混乱しない場合は、報復のために私に来てください」と効果的に顧客に伝えています。これが、リモートサーバー（アプレット/ Webスタート）からデプロイされたクライアント側ソリューションの署名付きjarが、署名なしソリューションよりも高い特権を享受する理由です。
JVMのセキュリティ要求を緩和する必要がないサーバー側のソリューションでは、この保証は顧客の安心のためだけのものです。
署名付きjarの悪い点は、署名なしjarよりも読み込みが遅いことです。どれくらい遅いですか？ CPUに依存しますが、読み込み時間が100％以上増加していることに気づきました。また、パッチはより難しく（jarに再署名する必要があります）、クラスパッチは不可能であり（単一のパッケージ内のすべてのクラスは同じ署名ソースを持っている必要があります）、jarの分割は面倒になります。言うまでもなく、ビルドプロセスは長く、適切な証明書には費用がかかります（自己署名はほとんど役に立たない）。
したがって、会社のポリシーで強制されない限り、サーバー側でjarに署名せず、一般的なjarを署名付きバージョンと署名なしバージョンで保持します（署名付きはクライアント側のデプロイメントに、署名なしはサーバー側のコードベースに移動します） ）。
正当な理由は、コードによって呼び出されるように変更されたクラスに誰かが忍び込むことができるようにしたくない場合です。
残念ながら、それはあなた自身を含みます:-Dしたがって、これは本当に必要な場合にのみ実行されます。 「密封された瓶」の概念を確認してください。
アプレットの観点から：Sun JREは6u10以降、警告バナーを目立たない（6u12以降のIIRC）警告三角形に置き換えます（形をした透明なウィンドウをサポートするために必要）。 6u10では、JNLPサービスAPIを介してファイルアクセスを制御することもできます。
最小特権の原則では、jarファイルのクラスに署名しないでください。セキュリティは必ずしも簡単ではありません。
証明書のダイアログボックスを表示するだけでは、Webページのコンテンツ全体が信頼されることを意味するものではありません。
他のコンテキストで証明書を使用するのと同じように、jarファイルへの署名は、それを使用した人々がどこから来たのかを知るために行われます。人々は、Chris Carruthersが悪意のあるコードを作成するつもりはないと信じているかもしれません。署名は、瓶が実際にあなたによって作成されたものであり、詐欺師や彼らが信頼していない誰かによって作成されたものではないことを保証します。
サーバーサイドまたはライブラリjarの場合、通常、そのような保証を誰にも提供する必要はありません。それがあなたのサーバーであれば、あなたはあなたが使っているjarとそれらがどこから来たのかを知っており、おそらくあなた自身のコードが悪意のないものであると信頼しているでしょう。