Зачем мне подписывать файлы JAR?
Я знаю, что мне нужно подписать мои JAR файлы на стороне клиента (содержащие апплеты), чтобы можно было выполнить специальные действия, такие как доступ к файловой системе, и чтобы раздражающий бит в нижней части окна не показывался, но почему еще? И мне нужно подписать мои серверные JAR файлы, содержащие сервлеты и т.д.?
Некоторые базовые правила для того, когда и когда не подписывать JAR, будут оценены - спасибо!
Короткий ответ - не делайте, если ваша политика компании не заставит вас.
Длинный ответ
Подписывающие банки эффективно сообщают вашему клиенту: "Я сделал это, и я гарантирую, что это не испортит вашу систему. Если да, придите ко мне за возмездие". Вот почему подписанные банки в клиентском решении, развернутом с удаленных серверов (апплеты/веб-сайт), обладают более высокими привилегиями, чем не подписанные решения.
В решениях на стороне сервера, где вам не нужно успокаивать требования безопасности JVM, эта гарантия предназначена только для спокойствия вашего клиента.
Плохая вещь о подписанных банках заключается в том, что они загружаются медленнее, чем неподписанные банки. Насколько медленнее? он связан с CPU, но я заметил увеличение времени загрузки более чем на 100%. Кроме того, исправления сложнее (вам нужно повторно подписать банку), классовые исправления невозможны (все классы в одном пакете должны иметь один и тот же источник сигнатуры), а разделение банок становится сложной задачей. Не говоря уже о том, что ваш процесс сборки длиннее и что соответствующие сертификаты стоят денег (самозаверяющий находится рядом с бесполезным).
Итак, если ваша политика компании не заставит вас, не подписывайте банки на стороне сервера и не держите общие банки в подписанных и не подписанных версиях (подписанный перейдите на клиентскую версию, не подписанный перейдите на сервер -side codebase).
Хорошая причина может заключаться в том, что вы никогда не хотели, чтобы кто-то мог прокрасться в modfied классы, которые вызывают по вашему коду.
К сожалению, это включает в себя: -D Так что это нужно делать только в том случае, если вам это действительно нужно. Проверьте концепцию "запечатанной банки".
С точки зрения апплетов: от 6u10 Sun JRE заменяет предупреждающий баннер с менее навязчивым (из 6u12, IIRC) предупреждающим треугольником (необходимо для поддержки форменных и прозрачных окон). 6u10 также позволяет управлять доступом к файлам через API сервисов JNLP.
Принцип наименьшей привилегии говорит, что вы не должны подписывать классы ваших файлов jar. Безопасность не всегда проста.
Простое отображение диалогового окна сертификата не должно толковаться как означающее, что нужно доверять всему содержимому веб-страницы.
Подписание файла jar, так же, как использование сертификатов в других контекстах, выполняется так, чтобы люди, использующие его, знали, откуда оно взялось. Люди могут доверять, что Крис Каррутерс не собирается писать вредоносный код, и поэтому они готовы разрешить вашему апплетам доступ к своей файловой системе. Подпись дает им определенную гарантию того, что банка действительно была создана вами, а не самозванец или кто-то, кому они не доверяют.
В случае серверных или библиотечных банок обычно нет необходимости предоставлять такую гарантию кому-либо. Если это ваш сервер, то вы знаете, какие банки вы используете и откуда они пришли, и вы, вероятно, доверяете своему собственному коду не быть злонамеренным.