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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

Answer 3

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

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