mirrord项目在macOS上获取公共证书文件失败问题分析

问题背景

在macOS系统上使用mirrord工具执行Erlang/Elixir项目时，发现从3.106.0版本开始出现无法获取公共证书文件的问题。这个问题会导致任何SSL/TLS相关操作都无法正常工作。

问题表现

当尝试通过mirrord执行Elixir命令获取CA证书时，会出现如下错误：

:public_key.cacerts_get()
** (ArgumentError) construction of binary failed: segment 2 of type 'binary': expected a binary but got: [70, 97, 105, 108, 101, 100, 32, 116, 111, 32, 108, 111, 97, 100, 32, 99, 97, 99, 101, 114, 116, 115, 58, 32, ~c"operation failed with status 137"]

错误信息表明系统在尝试构建二进制数据时失败，无法正确加载CA证书。

技术分析

版本回溯

经过测试发现：

• 3.104.0版本可以正常工作
• 3.105.0版本开始出现问题

查看3.105.0版本的变更记录，发现该版本包含了对readlink shims的修改。考虑到大多数开发者会通过Homebrew安装OpenSSL，而Homebrew的OpenSSL通常是一个符号链接：

/opt/homebrew/opt/openssl@3@ -> ../Cellar/openssl@3/3.4.1

这种符号链接的处理方式变更可能是导致问题的原因。

macOS系统因素

在后续调查中发现，升级macOS系统可以解决此问题。推测可能是由于SIP(System Integrity Protection)的补丁缓存机制在不同版本间持续存在导致的兼容性问题。

解决方案

对于遇到此问题的用户，可以尝试以下解决方案：

1. 升级macOS系统：这是最直接的解决方案，可以清除潜在的SIP缓存问题。

2. 降级mirrord版本：如果暂时无法升级系统，可以回退到3.104.0版本。

3. 手动指定证书路径：在Elixir/Erlang项目中手动配置证书路径，绕过自动获取机制。

技术建议

对于依赖SSL/TLS的Erlang/Elixir项目开发者，建议：

1. 在项目中明确指定证书路径，而不是依赖系统自动发现机制。

2. 考虑使用certifi等Erlang库来管理证书，提供更稳定的证书来源。

3. 在容器化部署时，确保基础镜像中包含完整的证书链。

总结

这个问题展示了系统安全机制、工具链更新和语言运行时环境之间复杂的交互关系。作为开发者，理解这些底层机制有助于更快地诊断和解决类似问题。同时，这也提醒我们在依赖系统级功能时需要考虑更健壮的备选方案。