.NET OpenSource проекты и сильные имена сборок?

В настоящее время я думаю об открытии моего проекта, и я готов в процессе подготовки исходного кода и структуры проекта для публикации. Теперь у меня есть один вопрос: как я должен обрабатывать ключ подписи для своих сборок? Должен ли я создать новый ключ для версии с открытым исходным кодом и опубликовать его вместе с другими файлами в репозитории SVN? Должен ли я оставить ключ, и каждый, кто хочет скомпилировать код, должен создать свой собственный ключ?

Как вы справляетесь с этим? Я чувствую себя немного неудобно с выпуском ключа подписи для публики.

Ответ 1

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

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

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

Ответ 2

Не отпускайте ключ.

Вам ДОЛЖНО чувствовать себя некомфортно, выпуская ключ подписи для общественности. Это не подпись проекта. Это ВАША подпись. Целостность подписи в двоичном файле сохраняется только в том случае, если вы сохраняете секретный ключ. Освобождение ключевых подрывников означает смысл и намерение подписанных сборок и сильное именование, что открывает новые возможности для ошибок и, таким образом, делает каждую систему менее надежной. Не отпускайте ключ.

Для DotNetZip я не выпускаю ключ. Но вот ключевой момент: ключ не принадлежит проекту; это мой ключ. Многие люди попросили ключ, чтобы они могли перестроить подписанный двоичный файл, но это не имеет смысла. Я использую ключ для подписки больше, чем DotNetZip. Любой бинарный файл, подписанный с этим ключом, подписывается мной по определению. Любые два бинарных файла, которые имеют одинаковое сильное имя с использованием моего ключа, гарантированно будут идентичны. Освобождение ключей устраняет эти гарантии и побеждает всю цель сильных имен и безопасность, окружающую их.

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

Представьте, если бы я смог подписать любую сборку с помощью ВАШЕГО ключа. Если вы отпустите свой ключ, я могу добавить любой код, который мне понравился - даже вредоносный код, - а затем подписать его и незаметно заменить любой "хороший" подписанный вами двоичный код с "плохим". Никто не сможет сказать разницу.

Это сломано. Свободно используемые ключи устраняют любое преимущество использования подписанных сборок вообще.

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

Ответ 3

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

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