.NET: Должны ли исполняемые файлы иметь строгую подпись? А как насчет частных DLL?

Question

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

Должны ли эти сборки иметь строгое название?

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

CA2210: знак со строгим именем.

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

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

и

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

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

Edit:

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

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

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

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

Редактировать 2:

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

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

Answer 1

На мой взгляд, это преимущества подписи под строгим именем в этой ситуации:

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

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

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

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

Answer 2

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

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

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

Сборка со строгим именем может быть заменена сборкой со строгим именем; который поднимает вопрос о том, что строгие имена НЕ являются какой-либо функцией безопасности.

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

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

Answer 3

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

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

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

Answer 4

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

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

Я не вижу необходимости называть exe.

только мои 2 песо ....