Лучшие практики для подписания сборок .NET?

Если ваша единственная цель - не дать FxCop кричать на вас, значит, вы нашли лучший способ.

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

• Для личного пользования
• Для использования на ПК корпоративной сети в качестве клиентского приложения
• Работает на веб-сервере
• Запуск в SQL Server
• Скачал из интернета
• Продается на компакт-диске в термоусадочной пленке.
• Загружается прямо в кибернетический мозг
• И Т. Д.

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

ОБНОВЛЕНИЕ. При развертывании через Интернет это принесет пользу вашим конечным пользователям, если вы получили сертификат подписи программного обеспечения от центра сертификации. Затем, когда они загружают ваши сборки, они могут убедиться, что они получены из Domenic's Software Emporium, и не были изменены или повреждены в процессе. Вы также захотите подписать установщик, когда он будет загружен. Это предотвращает появление предупреждения, которое отображается в некоторых браузерах, что оно было получено из неизвестного источника.

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

Наиболее очевидное различие между подписанными и неподписанными сборками заключается в приложении ClickOnce. Если вы не подпишете его, то при первом запуске вашего приложения пользователи получат устрашающее диалоговое окно с предупреждением «Неизвестный издатель». Если вы подписали его с помощью сертификата доверенного центра, они увидят менее пугающий диалог. Насколько мне известно, подписание сертификатом, который вы сгенерировали самостоятельно, не влияет на предупреждение «Неизвестный издатель». Instant SSL от Comodo содержит примеры диалоговых окон.

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

Это помогает, потому что исполняемый файл ожидает сборку со строгим именем. Он предотвращает злонамеренную замену вашей сборки другой сборкой. Также пользователь может предоставить сборке разрешения CAS на основе строгого имени.

Я не думаю, что вам следует распространять файл .pfx, вы сохраните его, чтобы отказаться от сборки.

Важно хранить свой PFX-файл в секрете, поскольку он содержит закрытый ключ.

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

Чтобы связать ваше имя с вашими сборками (в глазах Windows), вам понадобится цифровой сертификат (часть PFX-файла, содержащая ваше имя), подписанный доверенным центром.

Фактически вы получите новый сертификат, но с той же информацией.

Вам придется платить за этот сертификат (вероятно, ежегодно), но центр сертификации будет эффективно поручиться за свое существование (после того, как вы отправите им по факсу копии вашего паспорта или водительского удостоверения и внутреннего счета).

Подпись используется для однозначной идентификации сборки. Дополнительные сведения см. В Как подписать Сборка (Visual Studio).

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