Cryptomator项目Windows安装包签名失败问题分析

问题背景

在Cryptomator项目的持续集成过程中，Windows安装包的构建流程突然开始失败。具体表现为在签名阶段出现错误，导致无法生成有效的Windows安装程序。这个问题首次出现在项目的一个提交之后，经过调查发现与JDK打包工具链的变化有关。

技术分析

错误现象

签名工具(signtool.exe)在执行时返回错误代码1，并显示错误信息"0x800700C1"。这个错误代码通常表示文件格式无效或损坏。更具体地说，错误提示表明在尝试修改已签名的可执行文件时遇到了问题。

根本原因

深入分析后发现，问题的根源在于Temurin JDK的一个变更。从某个版本开始，JDK开始对其打包工具链中的文件(包括wixhelper.dll和jpackageapplauncher.exe)进行预签名。当jpackage工具使用这些已签名的文件作为模板创建新的可执行文件时，会修改文件内容，导致签名失效。

Windows签名机制的特殊性

Windows平台对可执行文件的签名验证有一个特殊机制：任何对已签名可执行文件的修改都会使签名失效。这与常见的哈希验证机制类似，但执行更加严格。当jpackage修改已签名的模板文件来创建应用启动器时，这种修改触发了Windows的签名验证机制，导致后续签名步骤失败。

解决方案

临时解决方案

在发现问题后，项目团队发现使用Zulu JDK而不是Temurin JDK可以避免这个问题，因为Zulu版本尚未对其打包工具链中的文件进行预签名。这提供了一个临时的解决方案，使构建流程能够继续工作。

长期解决方案

从长远来看，需要等待JDK打包工具链提供对这种情况的适当处理。可能的解决方案包括：

1. JDK打包工具应该在修改模板文件后重新签名
2. 提供未签名的模板文件选项
3. 改进签名流程，使其能够正确处理预签名的模板文件

经验总结

这个案例展示了软件供应链中一个有趣的问题：底层工具链的变化如何影响上层应用的构建流程。它也提醒我们：

1. 构建环境的变化可能带来意想不到的后果
2. 签名机制在不同平台上有不同的实现和限制
3. 在持续集成中，对构建工具的版本选择需要谨慎考虑

对于使用jpackage工具打包Windows应用的其他项目，这个案例也提供了有价值的参考，特别是在处理应用签名时可能遇到的问题。