Должен ли каждый проект подписываться отдельным ключом сильного имени (.snk)?

В моем решении Visual Studio у меня есть веб-сайт и 4-5 проектов библиотеки классов, на которые ссылаются. Некоторые из них также ссылаются на внешние сторонние сборки.

Мне поручено подписать сборки для этих проектов.

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

Должен ли я использовать один сингл с сильным именем (.snk) для подписания всех сборок этих проектов или каждая сборка должна быть подписана с помощью отдельного сильного имени?

Какова цель защиты паролем для сильных именных ключей?

Как вы это сделаете?

Большое спасибо,

Ответ 1

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

Нет. Подпись проверяет вас, издателя. Это не позволяет другим создавать "поддельные" версии ваших сборок.

Должен ли я использовать один сингл с сильным именем (.snk) для подписания всех сборок этих проектов или каждая сборка должна быть подписана с помощью отдельного сильного имени?

Ключ - это ваша подпись, поэтому используйте 1 для всех своих проектов.

Какова цель защиты паролем для сильных именных ключей?

Весь процесс подписания зависит от того, что вы являетесь единственным, у кого есть ключ. Сертификата нет. Частичное подписание и защищенные ключи могут помочь вам ограничить количество людей, имеющих доступ к ключу.

Ответ 2

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

С другой стороны, цифровая подпись сборки идентифицирует создателя этой сборки.

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

Другая подпись, называемая подписанием кода, использует специально созданные сертификаты только для подписи кода и связывает вместе с двоичным файлом общедоступный сертификат с именем, обычно идентифицирующим разработчика, вместе с цепочкой сертификатов, проверяющей подпись, до центра сертификации, который может в свойствах файла с помощью проводника Windows, первый случай не виден в проводнике Windows, и он может без проблем использовать самозаверяющий сертификат, созданный в visual studio.

На самом деле, код с цифровой подписью предназначен для всех видов кода, он не должен быть сборкой .NET, это может быть простая DLL-библиотека Win32 API или EXE.