Каков рекомендуемый способ управления парой ключей со строгим именем для проекта с открытым исходным кодом?

Question

Я управляю проектом с открытым исходным кодом и хочу подписать двоичные файлы, выпущенные в двоичном пакете проекта. Я использую файлы Visual Studio csproj и sln для управления и создания своего проекта, а также распространяю эти файлы как часть исходных пакетов проекта.

Как я могу подписать созданные двоичные файлы моей сборки и не должен распространять файл пар ключей snk? Если я использую Visual Studio для подписи сборок, то для создания каждого файла проекта теперь требуется копия пары ключей. Мне неудобно распределять пару ключей, даже если она защищена паролем.

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

Еще одно предостережение: некоторые сборки в проекте предоставляют доступ к друзьям через InternalsVisibleToAttribute и создают этих друзей по ссылке на проект. Следовательно, такие сборки должны использовать строгое имя при ссылке на подписанную сборку. Однако, если пара ключей не распределена, то как конечные пользователи могут создавать источники и поддерживать отношения проекта? Если используется временный файл пары ключей, не изменится ли токен открытого ключа подписанных сборок, сломав ссылки InternalsVisibleToAttribute?

Answer 1

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

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

Answer 2

Решение Sharptooth работает хорошо, если в коде содержатся только ссылки на сборки, закодированные в файлах проекта. Если ваш проект ссылается на другие сборки с помощью InternalsVisibleToAttribute или другими способами, где требуется строка строгого имени, то невозможно создать источники хранилища с временным ключом. Это приведет к изменению ссылок на открытый ключ, присутствующих в строках со строгими именами, и нарушит код.

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

Я в основном создал копию файлов sln и csproj в отдельной иерархической папке и изменил файлы csproj следующим образом.

• Преобразованы все ссылки на файлы в ссылки, указывающие на исходные источники.
• Скопировал и изменил каждый файл AssemblyInfo.cs для использования InternalsVisibleToAttribute со строгим именем.
• Изменен каждый файл csproj, чтобы ссылка на файл snk представляла собой относительный путь (избавляет от необходимости копировать файл snk в каждый проект)

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

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

Источники в репозитории не собирают сборки со строгими именами, что нормально, так как я не хотел бы налагать какие-либо ограничения или процессы сборки на конечных пользователей.

Answer 3

Это старый вопрос, но ответ, получивший наибольшее количество голосов, не является точным, поэтому я решил, что стоит опубликовать новый ответ.

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

См. Здесь для справки: https://docs.microsoft.com/en-us/dotnet/framework/app-domains/strong-named-assemblies

Не полагайтесь на строгие имена для обеспечения безопасности. Они предоставляют только уникальную личность.

Они также специально предназначены для проектов с открытым исходным кодом:

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

Если вы хотите обеспечить безопасность своих сборок, вам следует изучить Подпись с помощью Authenticode : https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assemblies/