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

В частности, сборка библиотеки классов. Мои первоначальные мысли:

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

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

Ответ 1

Недавно я столкнулся с той же проблемой в проекте с открытым исходным кодом, который поддерживаю. Вот как я затронул эту проблему:

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

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

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

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

Ответ 2

Я бы не против, если больше проектов, которые вы, вероятно, собираетесь использовать только как refrence вместо редактирования и повторной компиляции, предложит "подписанную" версию dll. Это помогло бы доверять отказу от существующего .dll быстрее, чем проверять код и компилировать его.

Во многих проектах с открытым исходным кодом есть своего рода "родитель" усилий, думаю, что Линус или даже John Gruber для Примеры. Эти люди могут держать ключ или распространять его на доверенного администратора для подписания основных выпусков.

Ответ 3

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

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

Ответ 4

В Open Source "источник" открыт. Бинарники обычно предоставляются только для товара.

Источник не нужно подписывать, если двоичный файл подписан, тогда генератор двоичного файла также является владельцем секретного ключа (который должен храниться в секрете).

Ответ 5

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

В более широком контексте нужно признать, что .net действительно не поддерживает повторное использование сборок между несколькими установленными приложениями. Посмотрите в свою папку SxS! Таким образом, другой путь всегда был бы для дистрибьютора сборки подписать его своим ключом. например если проект использует log4net, он должен подписать сборку log4net со своим собственным ключом, чтобы взять на себя ответственность за ее содержимое.

Ответ 6

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

Ответ 7

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

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