Отменяет ли Qt цифровые подписи своих собственных библиотек во время сборки?

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

Сегодня я заметил как в Jenkins, так и в потоках сборки TFS, где при использовании проектов Qt в журналах появляется этот маленький двухстрочный код:

15:24:19 Обновление Qt5Core.dll.
15:24:19 Исправление Qt5Core.dll...

Затем позже в журналах сборки для Jenkins его цифровая подпись была безуспешно проверена, а затем подписана с помощью тестового сертификата:

15:24:19 call "C:\Program Files (x86)\Windows Kits\10\bin\x64\signtool.exe" verify /pa C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll
15:24:19 IF NOT "!errorlevel!" == "0" echo Self-Signing C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll & call signtool sign /f C:\DevOps\test_certificates\cert.pfx /fd SHA512 C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll && set something_signed=true
15:24:19 )
15:24:19 Файл: C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll
15:24:19 Отметка времени алгоритма индексирования
15:24:19 ============================== =========
15:24:19
15:24:19 Количество ошибок: 1

15:24:19 Ошибка SignTool: Подпись не найдена.
15:24:19 Самоподписание C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll
15:24:19 Добавление дополнительного хранилища выполнено 15:24:19 Успешно подписано: C:\ Папка сборки\артефакты\qt5611_win32-msvc2015\релиз\Qt5Core.dll

Что-то из QMake или JOM делает цифровую подпись этого Updating/Patching недействительной? Если да, то неизбежно ли это? Я не очень хорошо разбираюсь в создании проектов Qt в других операционных системах, но я помню, что мне нужно было использовать некоторые инструменты, чтобы изменить то, на что указывали библиотеки. Лучшее, что я могу предположить, это то, что что-то подобное происходит за кулисами с WinDeployQt.

Это то, что выполняется прямо перед первыми двумя строками в кавычках, если вам интересно, что сообщал WinDeployQt:

15:24:18 link /NOLOGO /DYNAMICBASE /NXCOMPAT /INCREMENTAL:NO /SUBSYSTEM:CONSOLE "/MANIFESTDEPENDENCY:type='win32' name='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='removed-by-OP' language='*' processorArchitecture='*'" /MANIFEST:embed /OUT:C:\BuildFolder\bin\release\qt_test_build.exe @C:\Users\USER~1\AppData\Local\Temp\qt_test_build.exe.4012.485.jom
15:24:19 windeployqt -core --no-compiler-runtime --no-quick-import --no-translations C:\BuildFolder\solution_directory\..\bin\release\qt_test_build.exe
15:24:19 C:\BuildFolder\bin\release\qt_test_build.exe 64-разрядная версия, исполняемый файл
15:24:19 Direct зависимости: Qt5Core
15:24:19 Все зависимости: Qt5Core
15:24:19 Будет развернуто: Qt5Core


build qt signtool digital-signature qmake
person kayleeFrye_onDeck    schedule 17.02.2017    source источник

Ответы (2)


arrow_upward
3
arrow_downward

qmake ничего не изменяет, кроме вывода: его единственная задача — генерировать скрипты сборки для другой системы сборки.

jom — это инструмент создания, и он делает то же, что и nmake, за исключением нескольких параллельных процессов, если это возможно. Он просто следует указаниям в make-файлах. Я не знаю ни одного кода в qmake, который генерировал бы действия makefile, изменяющие сами библиотеки Qt, если только вы не поместите что-то явное в файл проекта, что вызовет это. Я тоже никогда не видел, чтобы это произошло.

Это оставляет windeployqt, и он исправляет двоичные файлы Qt после того, как они скопированы в целевое расположение, поскольку двоичные файлы содержат некоторые встроенные пути и т. д. Если вы вызываете windeployqt через ваш make-файл/файл проекта, он появится как будто Qt был изменен изнутри job.

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

Увы, есть простое решение: подписывайте вещи прямо перед сборкой установочного пакета — это обязательно будет после windeployqt. У меня работает (тм). Статическая сборка, возможно, также может быть вариантом, если ваш продукт состоит из одного исполняемого файла или может быть сделан таким образом.

person Kuba hasn't forgotten Monica    schedule 18.02.2017
comment
Даг наммит! У меня было ощущение, что это то, что происходит, или что-то подобное ›_‹ Я думаю, что возможно сделать их выходные местоположения статически подписанными и зафиксированными для DLL Qt. Я, вероятно, сойду с рук с этим для небольших репозиториев, но у меня есть ощущение, что Мать Милосердие в DevOps вырвет линейку и встанет на колени xD Но это моя проблема, а не ваша! Спасибо, Куба Обер! - person kayleeFrye_onDeck; 18.02.2017

arrow_upward
1
arrow_downward

В Qt 5.14.2 дела пошли лучше.

В более старой Qt 5.13.2 я могу найти qt_prfxpath= в Qt5Core.dll, за которым следует мой локальный путь к этому файлу. windeployqt заменяет этот путь на "." и пишет в лог об этом:

Исправление Qt5Core.dll...

После этого «исправления» подпись Authenticode для Qt5Core.dll становится действительной (она недействительна в моем локальном файле d:\Qt\5.13.2\mingw73_64\bin\Qt5Core.dll). Похоже, что установщик Qt исправляет Qt5Core.dll и windeployqt восстанавливает его до заводского состояния по умолчанию. ИМХО, это было ужасное дизайнерское решение.

Теперь, в Qt 5.14.2, я больше не вижу "qt_prfxpath=" и windeployqt не исправляет его. Подпись моего локального файла d:\Qt\5.14.2\mingw73_64\bin\Qt5Core.dll уже действительна.

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

person Aleksandr    schedule 20.05.2020
comment
Это приятно слышать! Я думаю, что это был просто плохой артефакт, когда они перенесли свой процесс с * nix на Windows. Обычно вам приходится исправлять расположение библиотек при их копировании и объединении, изменяя путь или что-то в этом роде для выделенных автономных модулей/приложений, если предполагается, что они не устанавливаются пользователем независимо. В среде Windows это проще, а поиск путей по изображениям следует установленной схеме, что делает его довольно удобным для простого копирования их прямо в каталог без изменения файла. tl; dr это, вероятно, было слишком сложным и проблематичным раньше. - person kayleeFrye_onDeck; 29.05.2020