Кто должен владеть закрытым ключом, используемым для подписания блока.NET, когда его проект является открытым исходным кодом? [закрытый]
Строго говоря, блок библиотеки классов. Мои начальные мысли:
- Имейте некоторых назначенных администраторов, делают все подписание блока. Но тогда когда исправления ошибок и новые версии записаны, двоичные файлы в конечном счете зависели бы от них являющийся вокруг (даже если его просто небольшое изменение по частным причинам).
- Ключ мог быть общедоступным. Но это идет вразрез с методами криптографии с открытым ключом, и Вы теряете преимущество доверия и идентификационных данных.
- Позвольте разработчикам конца и дистрибьюторам подписывать его со своими собственными ключами. Но тогда Вы теряете модуляризацию, так как каждое новое подписание делает ее несовместимой с некоторыми из других версий.
Несомненно, Вы не могли просто подписать блок. Но если другой проект, который требует их сборки, чтобы быть подписан, ссылается на Вашу библиотеку, Вы получаете ошибку компиляции.
7 ответов
Недавно я столкнулся с той же проблемой в проекте с открытым исходным кодом, который я поддерживаю. Вот как я решил эту проблему:
- Исходные коды всегда доступны для загрузки через репозиторий, но выпуск будет состоять из моментального снимка исходных текстов и скомпилированной версии.
- Перед тем, как сделать скомпилированную версию доступной, я подписываю сборки своим закрытым ключом.
Итак, в вашем случае, тот, кто готовит релиз, должен владеть ключом. Разработчикам библиотеки вообще не нужно знать об этом.
Если конечные пользователи хотят перекомпилировать и подписывать своими собственными ключами, это нормально. Вы можете отличить свои двоичные файлы от других, сравнивая открытый ключ, который присутствует в подписанных сборках. Сделайте открытый ключ доступным, и другие смогут сделать то же самое.
Управление этим процессом становится немного обременительным, когда InternalsVisibleToAttribute используется для ссылки на сборки со строгими именами. Вы можете прочитать о том, как я решил эту проблему здесь .
Я бы, например, не возражал, если бы больше проектов, которые вы, вероятно, будете использовать в качестве референции вместо редактирования и перекомпиляции, предлагали "подписанную" версию dll. Это помогло бы быстрее доверять референции к существующей .dll, чем проверять код и компилировать свою собственную.
Во многих проектах с открытым исходным кодом есть что-то вроде "Родительского" усилия, думаю, Линус или даже Джон Грубер для примера. Эти люди могли бы держать ключ или распространять его доверенному администратору для подписания основных выпусков.
Вопрос действительно вращается вокруг того, кто решает, что такое освобождение, не так ли? Если это так, то я думаю, что релизы должны быть подписаны личным ключом того, кто на самом деле несет ответственность за релиз. Если за создание релизов отвечают несколько человек, то нет ничего плохого в том, что они разделяют ключ, за исключением повышенного риска того, что им придется отозвать/переиздать ключ, если один из членов этой группы уйдет.
В более широком смысле, следует признать, что .net на самом деле не подходит для повторного использования сборок между несколькими установленными приложениями. Загляните в свою папку SxS! Другой способ - дистрибьютор сборки всегда должен подписывать ее своим ключом. Например, если проект использует log4net, он должен подписывать сборку log4net своим ключом, чтобы взять на себя ответственность за ее содержимое
.Насколько я помню, я никогда не сталкивался с подписанным проектом с открытым исходным кодом. Если мне понадобилась его подпись по какой-то причине, я подписал его сам. Я не вижу преимущества в подписании сборки как таковой. Если вас беспокоит подписание предварительно скомпилированной бинарной версии, то я бы сказал, что этот ключ должен быть только у руководства проекта. Человек, создающий подписанный проект, хотя должен быть полностью способен добавить исходный код в свой проект, или создать необходимую подпись проекта и скомпилировать его для себя.
.В Open Source открыт "исходный код". Двоичные файлы обычно предоставляются только для товаров.
Источник не обязательно должен быть подписан, если двоичный файл подписан, то генератор двоичного файла также является владельцем секретного ключа (который должен храниться в тайне)
.Храните закрытый ключ за пределами корня управления источником, но с относительной ссылкой на него. Таким образом, другие могут создавать сборки, используя свой собственный ключ. Они будут строго подписаны, но не официальные сборки.
Настройте автоматическую сборку, которая имеет полное дерево исходных текстов и закрытый ключ. Автосборка может делать официальные подписанные сборки, которые могут быть выпущены ночью или еще что-нибудь. Таким образом, создание официальной сборки происходит автоматически, так что уполномоченное лицо, имеющее закрытый ключ, не обязательно должно участвовать в этом (хотя у вас должен быть какой-нибудь механизм проверки патчей, предоставленных сообществом, перед включением в официальную сборку, но на самом деле это отдельная проблема)
.Сильное наименование не предназначено для обеспечения подлинности, валидации, защиты или чего-либо подобного. Его единственной целью является предоставление уникального идентификатора сборке или серии сборок. Это сделано для того, чтобы в GAC можно было иметь множество сборок с именем "Library", и когда ваше приложение запрашивает время выполнения для загрузки "Library", система знает, что это означает вашу сборку "Library", а не чужую.
В свете этого я бы просто включил сильный ключ имени в дерево исходных текстов. Если по какой-то причине ваш проект хочет предоставить аутентичность или что-то из этого, то вы, вероятно, хотите, чтобы Authenticode подпись, которая не свободна и на самом деле, вероятно, не нужна для проекта с открытым исходным кодом. Если вы решили пойти по этому пути и задаетесь вопросом, кому должен принадлежать ключ подписания кода, это становится скорее политическим вопросом.