Рекомендации по подписанию сборок с несколькими проектами и разработчиками

Мне нужны рекомендации и передовые методы применения подписанных сборок в организации, насчитывающей 30+ разработчиков, 20+ решений и 60+ проектов. Мы используем Visual Studio Team System 2008 и TFS.

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

Мои мысли на данный момент:

  • Каждое решение, которое обычно имеет от 3 до 20 проектов, будет иметь один ключевой файл .pfx, помещенный в корневую папку решения.
  • Каждое решение будет иметь уникальный надежный пароль для ключа.

Возникнут ли у нас проблемы при таком подходе?

Еще несколько идей:

  • Используйте один и тот же ключевой файл для всех проектов во всех решениях. Это упростит нам задачу? Это плохая идея? Это вообще возможно?
  • Должен ли каждый проект иметь свой уникальный ключ? Почему, почему нет?

Любой вклад, хороший / плохой опыт и рекомендации приветствуются. :)


person Jakob Gade    schedule 10.09.2009    source источник


Ответы (3)


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

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

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

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

person Nader Shirazie    schedule 10.09.2009
comment
Отлично, думаю, мы попробуем. Можете объяснить, как добавить файл в виде ссылки? Я не думаю, что знаком с этой особенностью VS. :) - person Jakob Gade; 10.09.2009
comment
При добавлении кнопка разделяется стрелкой справа. Нажмите на стрелку, и вы увидите Добавить как ссылку :) - person Kyle Rosendo; 10.09.2009
comment
Ну конечно. Спасибо. :) Но я думаю, что нам придется скопировать файлы .pfx в отдельные решения / проект, потому что невозможно скомпилировать проект, если сеть не работает и вы больше обращаетесь к файлу. В конце концов, мы заменим общий ключ секретной версией в процессе сборки TFS. - person Jakob Gade; 10.09.2009
comment
Для VS2015 добавление файла .pfx в качестве ссылки и выбор его на вкладке «Подписывание» приводит к невозможности получить контрольную сумму MD5 из файла ключа. Не удалось найти окно сообщения об ошибке файла. Но, что удивительно, после этого сборка кажется строго подписанной, и обычно она собирает и загружает другие строго подписанные библиотеки DLL. Тем не менее, это означает, что ссылка на ключи как на ссылки не является стандартной практикой, поэтому, возможно, лучше остаться с копированием ключей. - person avitenberg; 04.04.2016

В настоящее время мы используем один и тот же надежный ключ (.SNK) для каждого проекта в нашем решении. В зависимости от вашего проекта вы можете использовать разные ключи для каждого проекта.

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

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

person Kyle Rosendo    schedule 10.09.2009

Вы также можете сохранить ключ строгого имени в папке на корневом уровне, на том же уровне, что и все папки проекта. Когда вы выбираете этот файл в свойствах проекта -> вкладка подписи, ключевой файл копируется в папку проекта. Удалите этот файл. Откройте файл .csproj в блокноте. Найдите следующий тег mykey.snk Вручную отредактируйте путь к ключевому файлу, убедитесь, что вы указали относительный путь из папки проекта. Сохраните файл. Теперь откройте свойства проекта в Visual Studio. Вы можете увидеть, что путь обновлен и указывает на правильное местоположение.

person samiksc    schedule 18.10.2010