Как можно избежать подписи Authenticode сторонних библиотек в проекте .NET при автоматической сборке? - PullRequest
4 голосов
/ 07 июля 2011

Недавно мы приобрели сертификат для подписи кода, и я включил этап подписания кода в наши автоматические сборки.

Наш скрипт сборки должен создавать как проекты VB6, так и .NET, поэтому в настоящее время у нас есть пакетный файл, который собирает все. Для проектов .NET наш скрипт сборки вызывает MSBUILD, передавая файл решения для сборки. Проекты в этих решениях имеют некоторые сторонние зависимости, и во всех этих файлах включена опция Копировать локальный в Ссылки , поскольку они необходимы для запуска приложения. Кроме того, в некоторых проектах используется COM Interop, поэтому они имеют автоматически созданные сборки Interop (например, Interop.MSXML2.dll ), которые также копируются в выходную папку во время сборки.

Я пытаюсь найти простой код для подписи файлов, скомпилированных во время сборки (т. Е. наши сборки), и игнорирую сторонние библиотеки и сборки Interop, не прибегая к вызывать signtool.exe для каждой сборки отдельно.

В настоящее время я решил эту проблему, выполнив в сценарии сборки следующее:

  • Убедитесь, что сборка очищает все ранее созданные файлы
  • Скомпилируйте решение .NET с MSBUILD, указав выходную папку для сборки
  • Рекурсивно подпишите все двоичные файлы (EXE, DLL, OCX) в выходной папке с помощью signtool.exe . Это подписывает все, включая сторонние библиотеки и автоматически сгенерированные сборки Interop
  • Мои сторонние зависимости находятся в отдельной папке lib, поэтому я копирую все файлы из lib обратно в выходную папку сборки, перезаписывая копии, скопированные сборкой. Таким образом, эти файлы больше не подписываются, но наши сборки по-прежнему

Мой вопрос: есть ли лучший способ сделать это? Единственная альтернатива, которую я могу придумать, - это вызывать signtool.exe индивидуально для каждой сборки, для которой требуется подпись, но это может быть проблемой из-за количества проектов и количества изменений, происходящих в них (сборок переименовывать, перемещать, удалять по мере развития проектов). Кроме того, я не хочу догадываться, подписана ли конкретная сборка или нет, поэтому для меня наиболее логичным является циклический просмотр файлов и их массовая подпись.

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

Или, может быть, я поступаю совсем не так?

1 Ответ

1 голос
/ 07 июля 2011

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

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

Что касается строительства, я использую Visual Build Professional для управления всеми процессами сборки, и у него есть встроенный шаг подписи кода, который я использую для подписи всего, что копируется.Мой самый длинный проект развертывания - в общей сложности более 300 шагов, и он выполняет все, от подписи до загрузки.Я не связан с Kinook, но я пытаюсь продвигать программное обеспечение - я не могу себе представить, сколько времени это экономит мне на данной рабочей неделе.

...