深入解析actions/upload-artifact中Mac应用签名失效问题

在GitHub Actions工作流中，当开发者尝试构建、签名并上传Mac应用后，在另一个环境中下载使用时，经常会遇到应用签名失效的问题。本文将详细分析这一现象的原因，并提供可靠的解决方案。

问题现象分析

当开发者按照标准流程构建Mac应用并完成以下步骤时：

1. 构建应用(Application.app)
2. 代码签名
3. 公证(Notarize)
4. 钉书(Staple)
5. 上传到GitHub Actions的Artifact
6. 在另一个环境(如Ubuntu)下载使用

此时应用签名会失效，使用codesign --verify --deep命令检查会发现大量文件被标记为"已修改"。

根本原因

经过深入分析，发现问题根源在于actions/upload-artifact对符号链接(symlink)的处理方式。Mac应用的签名机制非常严格，会检查应用包内所有文件的内容和权限。而upload-artifact在上传过程中：

1. 无法正确处理符号链接，而是上传了链接指向的原始文件
2. 可能改变了文件权限和元数据
3. 破坏了应用包内部的文件结构完整性

这些细微变化足以导致MacOS的代码签名验证失败，即使文件内容本身没有实质性改变。

解决方案

推荐方案：使用tar压缩打包

最可靠的解决方案是在上传前使用tar命令打包整个应用包：

- name: Compress package
  run: |
    cd ${{ github.workspace }}/build
    mkdir ../tar
    tar -zcvf ../tar/package.tar.gz .
- name: Archive Mac build
  uses: actions/upload-artifact@v4
  with:
    name: mac-build
    path: tar/

下载后解压恢复：

- name: Restore Mac build
  uses: actions/download-artifact@v4
  with:
    name: mac-build
    path: tar/
- name: Uncompress package
  run: |
    cd ${{ github.workspace }}/tar
    mkdir ../build
    tar -zxvf package.tar.gz -C ../build

方案优势

1. 完整保留文件权限和符号链接
2. 保持文件系统结构不变
3. 压缩后上传可能减少传输时间
4. 单文件操作更可靠

技术背景补充

Mac应用的代码签名机制实际上是对应用包内所有文件创建了数字指纹。当任何文件(包括资源文件、库文件等)发生改变时，这些指纹就不再匹配，导致签名验证失败。常见的破坏签名的操作包括：

1. 修改文件内容(即使是一个字节)
2. 改变文件权限
3. 替换符号链接为实际文件
4. 改变文件时间戳
5. 重新排列文件在包中的存储顺序

因此，在CI/CD流水线中处理已签名的Mac应用时，必须格外小心文件系统的完整性。

总结

在GitHub Actions工作流中处理已签名的Mac应用时，直接使用upload-artifact可能会导致签名失效。通过先使用tar命令打包整个应用包，可以确保所有文件属性和结构得到完整保留，从而避免签名验证失败的问题。这一解决方案不仅适用于GitHub Actions，也可推广到其他需要传输已签名Mac应用的场景中。