Signal-Desktop项目中的可重现构建问题与DNS回退机制分析

Signal-Desktop作为Signal的桌面客户端应用，在Linux发行版Arch Linux上遇到了一个关于可重现构建(reproducible builds)的有趣技术问题。本文将深入分析这个问题的技术背景、产生原因以及最终解决方案。

问题背景

可重现构建是开源软件领域的一个重要概念，它要求在不同时间和环境下编译同一份源代码时，能够产生完全相同的二进制输出。Arch Linux社区在这方面做了大量工作，建立了自动化系统来验证软件包的可重现性。

在Signal-Desktop 7.1.1版本中，Arch Linux的可重现构建系统检测到Signal-Desktop的构建结果不一致。经过分析，发现问题出在一个名为dns-fallback.json的文件上。

技术细节分析

dns-fallback.json的作用

这个JSON文件包含了Signal服务的多个域名及其对应的IP地址列表，作为DNS查询失败时的备用方案。文件内容形如：

[
  {
    "domain": "cdn.signal.org",
    "endpoints": [
      {
        "family": "ipv4",
        "address": "52.85.243.122"
      },
      // 更多IP地址...
    ]
  }
  // 更多域名...
]

问题根源

问题的关键在于这个文件是动态生成的。Signal-Desktop的构建脚本中包含一个生成脚本(ts/scripts/generate-dns-fallback.ts)，它会在每次构建时查询最新的DNS记录并生成这个JSON文件。

当Signal服务的IP地址发生变化时(如storage.signal.org从142.250.74.115变为142.250.181.211)，重新构建就会产生不同的dns-fallback.json文件，导致最终二进制包不一致。在这个具体案例中，IP地址变化导致文件大小增加了1字节。

解决方案演进

临时解决方案

社区成员开发了一个独立项目，自动从Signal官方更新服务器提取dns-fallback.json文件，作为GitHub发布产物提供。这使得Linux发行版维护者可以获取与官方构建完全一致的DNS回退文件。

最终解决方案

Signal开发团队在后续版本中修改了构建系统，将dns-fallback.json作为预生成文件纳入版本控制，而不是在每次构建时动态生成。这一变更确保了不同构建环境下产生的二进制文件完全一致。

技术启示

1. 可重现构建的重要性：对于安全敏感的应用，可重现构建让用户能够验证二进制文件确实来自公开的源代码，没有植入后门或恶意代码。

2. 动态内容的处理：构建过程中应避免引入可变内容，如实时DNS查询结果。这类内容应作为静态资源管理。

3. 构建系统的设计：良好的构建系统设计应该考虑可重现性，特别是在开源和安全关键型应用中。

Signal-Desktop团队对这一问题的响应和解决，体现了对软件供应链安全的重视，也为其他开源项目处理类似问题提供了参考范例。