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

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

Страница MSDN о строгой подписи имени достаточно хорошо резюмирует две цели.

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

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

Основная цель подписи, которую я видел, как правило, связана с более техническими причинами, включая уникальную идентификацию (пространства имен иногда могут непреднамеренно конфликтовать) и предоставление сборки для GAC. В таких случаях публичный доступ к ключевому файлу не имеет последствий для безопасности, потому что они изначально не предназначались. Никаких гарантий доверия / происхождения не предоставляется, но уникальная идентификация все еще действительна. На странице MSDN в основном обсуждается этот сценарий; моменты, когда нужно и нельзя подписывать собрание; и окружающие детали.

Однако если вы подписываете сборку ради аутентификации - в частности, чтобы гарантировать потребителю, что сборка исходит из заявленного источника - то экзотерический (публично распространяемый) ключ полностью аннулирует это доверие. модель. То есть любой может произвольно изменить код вашего проекта, правильно перестроить и отказаться от ваших сборок, по сути, подделав вашу личность. К сожалению, на странице MSDN такое использование не рассматривается (вероятно, потому, что его следует рассматривать более широко как часть стратегии безопасности), но, тем не менее, это важно.

Наконец, имейте в виду, что существует два типа файлов сертификатов ключей, которые среда CLR / .NET использует для подписи сборок. Первый - это, как вы упомянули, СНК; это не защищено паролем. Второй - PFX, который на самом деле представляет собой защищенную паролем версию файла ключей SNK. Если этот пароль достаточно безопасен, то не возникает проблем с безопасностью при распространении защищенного PFX с вашим программным обеспечением с открытым исходным кодом. Visual Studio (и утилита генерации ключей командной строки), конечно, способны создавать и то, и другое.