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

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

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

Изменить:

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


visual-studio c# open-source assembly-signing strongname
person Steve Guidi    schedule 02.12.2009    source источник

Ответы (3)


arrow_upward
6
arrow_downward

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

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

person sharptooth    schedule 02.12.2009
comment
Поскольку мне нужно распространять файлы проекта и решения, и поскольку пара ключей требуется для построения решения (при включенной подписи), следует ли мне также распространять фиктивную пару ключей, чтобы конечные пользователи могли создавать без необходимости манипулировать файлами проекта? Кажется обременительным возвращать файлы проекта, которые отключают подпись, только для того, чтобы переключать этот параметр каждый раз при выпуске релиза. - person Steve Guidi; 02.12.2009
comment
Вы можете сделать следующее: добавить этап сборки, который будет проверять, существует ли файл .snk, и запустить sn.exe для создания нового, если это необходимо. Затем он будет построен прямо из репозитория для других пользователей. - person sharptooth; 03.12.2009
comment
Обеспечение подлинности издателя не является предполагаемой целью подписания строгого имени. Для этого вы должны использовать Authenticode. Собственная документация Microsoft рекомендует опубликовать файл SNK: docs .microsoft.com / en-us / dotnet / standard / assembly / - person ahelwer; 14.11.2019

arrow_upward
6
arrow_downward

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

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

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

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

Они также специально обращаются к проектам с открытым исходным кодом:

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

Если вам нужна безопасность для ваших сборок, вам следует изучить Подписание аутентификационного кода: https://blogs.msdn.microsoft.com/shawnfa/2005/12/13/authenticode-and-assembly/

person Chris Gillum    schedule 08.09.2018

arrow_upward
2
arrow_downward

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

Так обстоит дело с моим приложением, поэтому мне пришлось применить другой подход.

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

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

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

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

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

person Steve Guidi    schedule 07.12.2009