Pixie项目macOS CLI版本签名问题分析与解决

在Pixie项目的持续集成过程中，开发团队遇到了一个关于macOS平台命令行工具(CLI)版本签名的问题。这个问题直接影响了项目的发布流程，需要技术团队深入理解macOS应用签名机制的变化并找到合适的解决方案。

问题背景

Pixie项目在构建macOS平台的CLI工具时，使用了名为gon的工具进行代码签名和公证(notarization)流程。然而在最近的构建过程中，系统报错显示："Notarization of MacOS applications using altool has been decommissioned. Please use notarytool"。

这个错误表明Apple已经弃用了原有的altool公证工具，转而推荐使用新的notarytool工具。这一变化是Apple对开发者工具链进行现代化改造的一部分，旨在提供更高效、更安全的代码签名和公证流程。

技术分析

macOS应用签名和公证是确保应用安全性的重要环节。签名验证应用的来源和完整性，而公证则是Apple对应用进行额外安全检查的过程。在macOS生态中，这一流程经历了几个阶段的演变：

1. 传统签名工具：早期使用codesign进行签名，配合altool进行公证
2. 过渡阶段：Apple开始推荐使用notarytool替代altool
3. 当前阶段：altool已被完全弃用，强制使用notarytool

notarytool相比altool有几个显著优势：

• 更快的公证速度
• 更简洁的命令行接口
• 更好的错误报告
• 支持更现代的认证方式

解决方案

针对这一问题，Pixie团队采取了以下解决方案：

1. 移除对gon工具的依赖：由于gon工具已不再维护，且其内部仍使用已被弃用的altool，团队决定完全迁移到Apple官方推荐的notarytool

2. 重构构建脚本：

   • 使用xcrun notarytool代替原有的公证流程
   • 保持codesign进行基础签名
   • 实现新的zip打包逻辑

3. 自动化流程优化：

   • 简化证书管理
   • 改进错误处理机制
   • 增加公证状态检查

实施细节

在实际实施过程中，团队需要注意以下几个技术要点：

1. 证书配置：确保在CI环境中正确配置了开发者证书和公证凭证

2. 时间戳服务：签名时需要指定合适的时间戳服务URL，确保签名长期有效

3. 公证提交：正确构造提交包，包含所有必要的元数据

4. 结果查询：实现自动化的公证结果查询机制，避免阻塞构建流程

经验总结

通过解决这一问题，Pixie团队获得了以下宝贵经验：

1. 及时跟进平台变化：Apple开发者工具链更新频繁，需要保持对官方文档的关注

2. 工具链简化：直接使用平台原生工具往往比第三方封装更可靠

3. 构建流程弹性：CI/CD流程应该能够适应工具链的变化，避免过度依赖特定工具

4. 安全实践：代码签名和公证流程是应用安全的基础，需要认真对待

这一问题的解决不仅恢复了Pixie项目的正常发布流程，也为团队未来处理类似平台迁移问题积累了经验。同时，新的公证流程更加高效可靠，为项目的持续交付提供了更好的基础。