Wird Qt digitale Signaturen seiner eigenen Bibliotheken zur Build-Zeit ungültig machen?

Question

Wir haben ein paar Build-Systeme, die Qt verwenden. Da wir beim Signieren von Aufgaben Zeit sparen wollten und wir alle unsignierten Binärdateien signieren müssen, haben wir alle Qt-Binärdateien an ihrem Installationsort signiert und für einige unserer Paketmanager, die Qt-Abhängigkeiten verwenden, das Gleiche getan Setup-Typ, außer dass die Pakete anstelle des lokalen Qt-Verzeichnisses auf den Build-Slaves signiert sind. mit Qt-Projekte, ist diese kleine Zweizeiler zeigt sich in den Protokollen

Heute bemerkte ich sowohl auf Jenkins und TFS Build fließt, wo:

15:24:19 Updating Qt5Core.dll.
15:24:19 Patching Qt5Core.dll...

Dann später in den Build-Protokolle für Jenkins, seine digitale Signatur erfolglos überprüft wurde und dann mit einem Test-cert unterzeichnet:

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 File: C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll
15:24:19 Index Algorithm Timestamp
15:24:19 ========================================
15:24:19
15:24:19 Number of errors: 1

15:24:19 SignTool Error: No signature found.
15:24:19 Self-Signing C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll
15:24:19 Done Adding Additional Store 15:24:19 Successfully signed: C:\BuildFolder\artifacts\qt5611_win32-msvc2015\release\Qt5Core.dll

Ist etwas von QMake oder JOM die digitale Signatur von diesem Updating/Patching ungültig zu machen, das geschieht? Wenn ja, ist das unvermeidlich? Ich bin nicht sehr versiert darauf, Qt-Projekte auf anderen Betriebssystemen zu erstellen, aber ich erinnere mich, dass ich einige Tools verwenden musste, um zu ändern, wo auf die Bibliotheken verwiesen wurde. Das Beste, was ich herausfinden kann, ist, dass so etwas hinter den Kulissen mit WinDeployQt passiert.

Dies ist, was direkt vor den ersten beiden zitierten Zeilen ausgeführt wird, wenn Sie in welchem ​​WinDeployQt interessiert Berichterstattung wurde:

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 bit, release executable
15:24:19 Direct dependencies: Qt5Core
15:24:19 All dependencies : Qt5Core
15:24:19 To be deployed : Qt5Core

Answer 1

qmake etwas ändert nicht neben seinem Ausgang: seine einzige Aufgabe ist es zu erzeugen, Erstellen Sie Skripte für ein anderes Build-System.

jom ist ein make-Tool und macht was tun würde, außer in mehreren Prozessen parallel wenn möglich. Es folgt lediglich den Anweisungen in den Makefiles. Ich kenne keinen Code in qmake, der Makefile-Aktionen erzeugen würde, die Qt-Bibliotheken selbst verändern würden - es sei denn, Sie haben etwas explizit in die Projektdatei geschrieben, das das verursacht. Ich habe es auch nie gesehen.

Das lässt windeployqt, und es tut Patch Qt-Binärdateien, nachdem sie in das Zielverzeichnis kopiert werden, da die Binärdateien einige eingebettete Pfade usw. enthalten Wenn Sie windeployqt über Ihr Make-Datei/Projektdatei aufrufen, dann wird es erscheinen, als wenn Qt innerhalb von job geändert wurde.

Beachten Sie, dass die Qt-Binärdateien an den ursprünglichen Standorten, die Sie signiert haben, weiterhin bestehen bleiben. In der Tat sollte Ihre Qt-Installation nach dem Signieren schreibgeschützt gemacht werden und die Berechtigung so gesetzt sein, dass der Build selbst sie nicht durcheinander bringen kann, außer der Qt-Installationsschritt ist ein Teil des Builds selbst.

Leider gibt es eine einfache Lösung: Zeichen Sachen direkt bevor Sie Ihr Installationspaket bauen - das wird sicherlich nachwindeployqt sein. Funktioniert für mich (tm). Ein statischer Build könnte auch eine Option sein, wenn Ihr Produkt aus einer ausführbaren Datei besteht oder so erstellt werden könnte.