Почему я должен подписывать свои файлы JAR?

Question

Почему я должен подписывать JAR-файлы?

Я знаю, что мне нужно подписать свои JAR-файлы на стороне клиента (содержащие апплеты), чтобы можно было выполнять особые действия, такие как доступ к файловой системе, и чтобы не показывался раздражающий бит в нижней части окна, но почему еще ? И нужно ли мне подписывать JAR-файлы на стороне сервера, содержащие сервлеты и т. Д.?

Будем признательны за некоторые основные правила, когда и когда не следует подписывать JAR - спасибо!

Answer 1

Краткий ответ - нет, если только политика вашей компании не заставляет вас.

Длинный ответ
Подписание банок фактически говорит вашему клиенту: «Я сделал это, и я гарантирую, что это не испортит вашу систему. Если это произойдет, приходите ко мне за возмездием». Вот почему подписанные файлы JAR в клиентском решении, развернутом с удаленных серверов (апплеты / веб-запуск), имеют более высокие привилегии, чем не подписанные решения.

В решениях на стороне сервера, где вам не нужно успокаивать требования безопасности JVM, эта гарантия предназначена только для спокойствия вашего клиента.
Недостаток подписанных банок заключается в том, что они загружаются медленнее, чем неподписанные. Насколько медленнее? это связано с процессором, но я заметил, что время загрузки увеличилось более чем на 100%. Кроме того, исправления сложнее (вам нужно заново подписать jar), исправления классов невозможны (все классы в одном пакете должны иметь один и тот же источник подписи), и разделение jars становится рутиной. Не говоря уже о том, что процесс сборки длится дольше, а соответствующие сертификаты стоят денег (самоподписанный - почти бесполезный).

Таким образом, если политика вашей компании не заставляет вас это делать, не подписывайте jar на стороне сервера и сохраняйте общие jar в подписанной и не подписанной версиях (подписанные переходят в развертывание на стороне клиента, неподписанные переходят на сервер кодовая база).

Answer 2

Хорошая причина может быть в том, что вы никогда не хотели, чтобы кто-нибудь мог проникнуть в модифицированные классы, вызываемые вашим кодом.

К сожалению, это включает в себя :-D Так что это должно быть сделано только если вам действительно это нужно. Проверьте понятие «запечатанная банка».

Answer 3

С точки зрения апплетов: Начиная с 6u10 Sun JRE заменяет предупреждающий баннер на менее навязчивый (от 6u12, IIRC) предупреждающий треугольник (необходимый для поддержки профильных и прозрачных окон). 6u10 также позволяет контролировать доступ к файлам через API сервисов JNLP.

Принцип наименьших привилегий гласит, что вы не должны подписывать классы ваших jar-файлов. Безопасность не обязательно легка.

Простое отображение диалогового окна сертификата не должно истолковываться как означающее, что всему содержимому веб-страницы следует доверять.

Answer 4

Подписание файла jar, как и при использовании сертификатов в других контекстах, делается для того, чтобы люди, использующие его, знали, откуда он взялся. Люди могут полагать, что Крис Каррутерс не собирается писать вредоносный код, и поэтому они хотят разрешить вашему апплету доступ к своей файловой системе. Подпись дает им некоторую гарантию того, что баночка действительно была создана вами, а не самозванцем или кем-то, кому они не доверяют.

В случае серверных или библиотечных фляг обычно нет необходимости предоставлять такую ​​гарантию кому-либо. Если это ваш сервер, то вы знаете, какие файлы jar вы используете и откуда они пришли, и вы, вероятно, доверяете своему собственному коду, чтобы не быть вредоносным.