Qt是否在构建时使其自己的库的数字签名无效？

Question

我们有一些使用Qt的构建系统。由于我们希望节省签名任务的时间，并且我们需要签署我们分发的所有未签名二进制文件，我们继续在其安装位置签署所有Qt二进制文件，对于一些使用Qt依赖项的软件包管理器，同样安装类型，除了它的包被签名而不是构建从服务器上的本地Qt目录。

今天我注意到在使用Qt项目的Jenkins和TFS构建流程中，这个小小的两行显示在日志中：

  

15:24:19更新Qt5Core.dll。
  15:24:19修补Qt5Core.dll ......

然后在Jenkins的构建日志中，其数字签名未通过验证，然后使用test-cert进行签名：

  

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：\ BuildFolder \ artifacts \ qt5611_win32-msvc2015 \ release \ Qt5Core.dll

QMake或JOM来自此Updating / Patching的数字签名是否有效？如果是这样，这是不可避免的吗？我并不精通在其他操作系统上构建Qt项目，但我记得需要使用一些工具来改变libs指向的位置。我能想到的最好的事情是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直接依赖：Qt5Core
  15:24:19所有依赖关系：Qt5Core
  15:24:19部署：Qt5Core

Answer 1

除了输出之外，

qmake不会修改任何内容：它唯一的工作就是为另一个构建系统生成构建脚本。

jom是一个make工具，执行nmake将执行的操作，但如果可能的话，并行执行多个进程。它仅遵循makefile中的方向。我不知道qmake中会生成修改Qt库本身的makefile操作的任何代码 - 除非你在项目文件中放置一些明确的东西，否则会导致这种情况。我也从来没有见过它。

离开windeployqt，它会在复制到目标位置后修补Qt二进制文件，因为二进制文件包含一些嵌入路径等。如果您调用windeployqt通过你的makefile / project文件，它就好像Qt已经在job内修改过了。

观察您签名的原始位置的Qt二进制文件仍然如此。事实上，签名后的Qt安装应该是只读的，并且必须设置权限，以便构建本身不会弄乱，除非Qt安装步骤是构建本身的一部分。

唉，这是一个简单的修复：在您构建安装包之前签署内容 - 在 windeployqt之后肯定是。适合我（tm）。如果您的产品由一个可执行文件组成，或者可以这样做，那么静态构建也许也是一个选项。

Answer 2

在Qt 5.14.2中，情况变得更好。

在较旧的 Qt 5.13.2 中，我可以在Qt5Core.dll中找到 qt_prfxpath = ，其后是我对该文件的本地路径。 windeployqt 将此路径替换为“”。并写入日志：

正在修补Qt5Core.dll ...

在“修补” Qt5Core.dll的Authenticode签名后，它变为有效 （在我的本地文件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 不再是必需步骤。该实用程序有太多过多的库，至少对于我的项目而言是如此。我将摆脱它，并在我的构建脚本中显式复制所有内容。