6.4 代码签名与完整性校验

安全章最后一环走出应用内：保证用户拿到的二进制是你编译的那份，且系统愿意为它背书。本节讲 Windows 签名与 macOS 公证的配置方法、更新签名的独立密钥体系，以及"不签名"在各平台的真实代价。读完本节，出厂环节的完整性拼图齐了。

签名到底在证明什么

代码签名回答两个问题：这份二进制是谁出的（身份），出厂后有没有被改过（完整性）。原理是非对称签名：开发者持私钥对安装包签名，系统与用户用证书里的公钥验证。它防的是三类真实威胁——下载链路被劫持替换安装包、构建产物在内部流转时被篡改、假冒你产品的钓鱼分发。注意边界：签名不证明"代码没有漏洞"，只证明"漏洞是你写的"。

Windows：证书与配置

Windows 侧需要代码签名证书（CA 签发的 OV 或 EV 证书，EV 证书能减少 SmartScreen 的未知发布者警告积累期）。Tauri 把签名接进构建流程，配置在 bundle 段：

{
  "bundle": {
    "windows": {
      "certificateThumbprint": "证书指纹，certmgr 里查看复制",
      "digestAlgorithm": "sha256",
      "timestampUrl": "时间戳服务地址",
      "signCommand": "自定义签名命令（可选，进阶）"
    }
  }
}
​

四个字段的分工：certificateThumbprint 定位本机证书库里的证书；digestAlgorithm 用 sha256，别再用 sha1；timestampUrl 加时间戳——证书过期后，带时间戳的旧签名依然有效，这是最常被漏配也最该配的一项；signCommand 供硬件证书（U 盾、云签名服务）走自定义命令签名。CI 环境证书通常以环境变量注入，配合 signCommand 或构建脚本消费——私钥进代码仓库是重大事故，永远不要。

macOS：签名加公证两道工序

macOS 的完整性体系更严：签名（codesign）证明身份与完整性，公证（notarization）是苹果远程扫描你的二进制并签发通行证明。没公证的应用在 Gatekeeper 下默认被拦，用户要绕过右键打开——对普通用户等于劝退。Tauri 把两步整合进构建：

{
  "bundle": {
    "macOS": {
      "signingIdentity": "Developer ID Application: 证书名",
      "entitlements": "entitlements.plist 路径"
    }
  }
}
​

公证所需的苹果账号信息（团队 ID、密钥）经环境变量提供，构建时自动完成"签名、上传、钉票据"全套。三个实操要点：签名身份必须是 Developer ID Application 类型（分发用，与 Mac App Store 类型不同）；entitlements 按最小需要声明（沙箱类权限上架商店才必需，直分可不加）；每次构建全部二进制与库都要签名——Tauri 已代管，但如果你手工塞了第三方 dylib，记得补签，漏签是公证失败的头号原因。

更新签名：另一把钥匙

容易混淆的一点：安装包签名与应用更新签名是两套密钥、两个用途。更新签名由 Tauri 的 updater 体系使用——你用官方工具生成一对密钥，私钥在发布时给更新包签名，应用内置公钥在更新时验签。它防的威胁更具体：更新服务器被攻破后，攻击者推送伪造更新包——安装包签名对此无能为力，因为那验证的是"最初那份"，不是"下一份"。密钥生成与更新流程的完整实操在第 8 章自动更新一节，这里先立规矩：更新私钥与代码签名私钥分开保管，前者丢了等于放弃更新安全，且没有重置找回的余地——丢失后只能换公钥发版，已装用户收不到那次更新。

图 6-4：完整性的三道验证

Linux 与商店渠道

Linux 桌面常用分发的完整性由打包格式承担：deb 与 rpm 走发行版仓库签名体系，AppImage 可选签名。上架应用商店（Mac App Store、Microsoft Store）则用商店体系的证书与沙箱规则，与直分发配置不同——决定上架就要在 8.2 提前规划包类型与权限声明，两条渠道的包不通用。

不签名会怎样：用户视角的走查

配置节讲完，把镜头换到用户那头，看看"先发着、以后再签"的真实代价。Windows 上，未签名安装包撞上 SmartScreen：蓝色对话框写着"已保护你的电脑"，唯一的通行按钮叫"仍要运行"——藏在小字里，普通用户大多在这里放弃，敢于点进去的用户接下来还要面对浏览器与杀毒软件的第二轮告警。macOS 上，Gatekeeper 对未公证应用的处置更直接：双击弹出"无法验证开发者"并默认拒绝打开，正确路径是右键再选打开——这个动作对开发者是常识，对普通用户是玄学。Linux 桌面虽然宽松，但企业环境的审批系统同样会卡无签名包。

走查的结论不是"必须买最贵的证书"，而是签名状态是分发漏斗的第一道筛子——技术再好，用户在双击之后的三秒内就做出了去留决定。收益核算也简单：OV 证书的年费摊到安装用户上通常不到一分钱，而 SmartScreen 积累的"信誉"需要下载量与时间双要素，越晚签名越是拉长冷启动期。

签名的工程纪律：次序与保管

两件实操纪律，决定签名体系能不能长期稳定运转。**其一，签的是最终产物。**签名必须落在出厂安装包上——先打包、后签名、再分发，次序不可乱；签名后任何重压缩、改名、二次打包都会破坏签名，验证直接失败。CI 里把它固化成流水线的最后两步：构建产物归档，签名作业消费归档原件，禁止中间任何"顺手整理"。**其二，私钥的保管等级要与其权限匹配。**代码签名私钥泄露的后果是攻击者以你的身份发签名包，因此密钥不该在任何开发者的日常机器上落盘：团队规模小就用加密存储加最小接触面，规模大就上硬件令牌或云签名服务（这也正是 signCommand 存在的理由）。配合一条审计习惯：每次签名记录版本号、操作人与用途，出现"不认识的签名记录"时能立刻察觉异常。签名不是发布前顺手点一下的按钮，它是出厂制度的一部分——制度越平淡越好，平淡意味着每次出厂都一样可靠。

本节要点回顾

• 签名证明身份与完整性：防链路劫持、防篡改、防假冒，不防漏洞；
• Windows 四字段：指纹定位证书、sha256 摘要、时间戳必配、硬件证书走 signCommand；
• macOS 双工序：Developer ID 签名加公证，漏签第三方库是公证失败头因；
• 更新签名独立成套：内置公钥验下一份，私钥丢失不可找回；
• 不签名的真实代价：系统级警告与拦截，对普通用户等于劝退。

安全章收锁：总纲、门禁、边界、完整性四环齐备。下一章去标准件仓库取货——插件生态与系统集成。