.NET: Должны ли исполняемые файлы быть подписаны с сильным именем? Что относительно частных DLL?

Мое приложение состоит из трех сборок: одного EXE, который ссылается на пару DLL. DLL файлы являются приватными для моего приложения - они используются только этим исполняемым файлом.

Должны ли эти сборки иметь сильное имя?

FxCop предполагает, что они должны - для всех сборок, которые он в настоящее время производит:

CA2210: знак <assembly> с сильным именем.

Однако этот совет говорит:

В общем, вам следует избегать сильных имен приложений EXE-сборок.

и

вам может понадобиться избегать сильных имен компонентов, которые являются приватными для вашего приложения.

Должен ли я дать этим сборкам сильное имя? Каковы преимущества этого (или не делать этого) в этом случае?

Edit:

Рассматривая несколько приложений с аналогичной структурой, похоже, нет консенсуса по этому вопросу. Бинарные файлы Paint.NET и Crack.NET не являются с сильным именем, тогда как .NET Reflector и Snoop.

Интересно, что в пакете Expression Microsoft применяет последний подход: например, в Expression Blend они выбрали знак сильного имени как Blend.exe, так и связанных с ним DLL (например, Microsoft.Expression.Blend.dll).

Кажется, я вряд ли получу простой ответ на свой первый вопрос: "Должен ли я дать этим сборкам сильное имя?". Однако мой второй вопрос все еще стоит:

Есть ли какие-либо преимущества для двоичных файлов с сильным именем в этой ситуации? Или, есть ли преимущества, чтобы не делать этого?

Изменить 2:

Если нет каких-либо непреодолимых причин идти в любом случае, я склонен к тому, чтобы дать моим сборкам сильное имя. Меня, таким образом, интересовало, может ли кто-нибудь расширить это (из первой ссылки):

"сильное именование может затруднить управление зависимостями и добавление лишних накладных расходов для частных компонентов."

Ответы

Ответ 1

Как я вижу, это преимущества для подписи с сильным именем в этой ситуации:

  • Предотвращает замену злоумышленника DLL одной подписью с использованием другого ключа (или вообще не подписанного) без замены EXE (поскольку EXE содержит ссылку, которая включает открытый ключ).
  • Предотвращает изменение злоумышленником сборки при сохранении существующего ключа (поскольку это приведет к сбою проверки подписи). Обратите внимание, однако, что с .NET 3.5 SP1 проверка подписи в этой ситуации отключена по умолчанию.
  • Может помешать запуску приложения с несогласованными версиями сборок - если из-за ошибки развертывания была неправильно установлена ​​DLL, приложение не сможет загрузить его, а не пытается использовать (потенциально несовместимую) неправильную версию.
  • Предотвращает предупреждения FxCop.

И недостатки подписи (я считаю, что это ссылка на связанную статью):

  • Замена DLL на совместимую более новую версию (например, для исправления ошибки) требует замены EXE.
  • В версиях .NET < 3.5 SP1, узлы с сильными именами требуют больше времени для загрузки из-за проверки подписи.
  • Идентифицированные DLL с большими именами также занимают больше времени, поскольку загрузчик выполняет поиск (бесполезный в этой ситуации) GAC, прежде чем искать локально.

Похоже, что выбор - либо сильное именование (и, следовательно, требующее ссылки на соответствие точного ключа и точной версии), либо не сильное именование (и не требующее соответствия). Если бы можно было потребовать ключ, но не конкретную версию, возможно, можно было бы получить первые 2 преимущества подписи, не получив также первого недостатка. Возможно, это возможно, применяя сильное имя, а затем занимаясь проблемой управления версиями, используя app.config?

Ответ 2

Сильные сборки именования ТОЛЬКО обеспечивают совместимость версий. Это не то же самое, что доверять сборке.

Другими словами, "сильное имя" ТОЛЬКО относится к этому точному сборочному бинарнику в сочетании с номером версии, который используется во время компиляции.

Если вы GAC эти сборки, CLR проверяет только один раз. В то время сборка gac'd. Это может привести к повышению производительности. Однако мой опыт показал, что он минимален.

Сильная именованная сборка может быть заменена на сильную именованную; который поднимает роль о сильном наименовании, не являющемся элементом безопасности.

Мое личное мнение заключается в том, что связанный с ними уровень боли не оправдывает их использования. Боль в том, как они завинчиваются с помощью автоматизированных средств тестирования.

https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-5054496.html

Ответ 3

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

Конечно, это не абсолютная защита. Хакер может изменять сборки и удалять сильные сигнатуры имен (и ссылки) со всех сборок. Эти сборки также будут работать.

Но в таком случае вы можете сказать, что изменения не сделаны вами.

Ответ 4

Если вы подписываете сборку, любые ссылочные сборки публикуются публично, они также должны быть подписаны. В противном случае вы получите ошибку компиляции по уважительной причине.

Я думаю, что основное использование для сильного именования сборки - это получить ее в GAC.

Я не вижу необходимости сильного имени exe.

просто мои 2 песо....