您不需要可复制的构建

我对构建的重现性持怀疑态度，但热心的支持者们抓住每一个机会为其辩护和欢呼。经过几次激烈的讨论，我决定把我对这个话题的想法写下来。我将尽最大努力总结关于可重复构建的论点，并解释为什么我认为它们不能令人信服。支持者喜欢假装话题很简单，就像一位可再生性粉丝在Twitter上粗鲁地对我说的那样：“再生性很重要。通过可复制的构建通向二进制B的源代码A保证您所看到的(源代码)就是您所获得的(来自供应商的二进制代码)。这里还有什么不清楚的？“。

目前尚不清楚的是，可重复性提供了什么好处。验证不受信任的二进制文件与通过构建源代码生成的二进制文件是否逐位相同的唯一方法是，首先生成您自己的受信任的二进制文件，然后对其进行比较。在这一点上，您已经有了一个可以使用的可信二进制文件，那么可复制构建提供了什么价值呢？此图演示了如何在没有可重复生成的情况下获取可信的二进制文件。这个问题的答案是，可复制的构建不是给用户的，他们应该提名他们信任的人来为他们构建，并验证输出是正确的。修改后的工作流类似于第一个图表，但现在由可信的供应商负责编译步骤，因此问题是相同的。受信任的供应商无论如何都要生产二进制文件，为什么不直接使用它，使可重现的构建变得不必要呢？答案是，我们可以设计一个系统，在这个系统中，几个第三方可以复制二进制，我们可以要求他们所有人都同意一个二进制匹配。以下是该工作流程图。

此场景的问题在于，用户仍然必须信任供应商才能进行验证。如果受信任的供应商受到威胁，则他们可以提供被篡改的二进制文件。如果他们不妥协，那么与第三方复制它就没有任何好处。实际上，这与目前Linux发行版中系统的工作方式没有什么不同。这个问题的答案是，我们可以构建一个系统，其中用户只需信任供应商一次。如果供应商在此之后受到威胁，复制版本将阻止他们将篡改的包分发给用户。这有点复杂，用户不能通过自己编译来验证重新生成的构建，因为这样他们就已经有了一个受信任的构建。答案是用户提名他们信任的供应商，然后要求他们签名才能安装任何软件包。以下是该工作流：

现在，如果供应商受到攻击或变得恶意，他们不能在不提供源代码的情况下向用户提供任何受攻击的二进制文件。这忽略了一些复杂性，例如确保即使一个供应商受到威胁也能提供安全更新，如果复制器停止工作怎么办，或者如果复制器和供应商在您应该使用什么软件或分支上存在分歧时如何达成共识。无论如何，即使我们忽略这些实用性，此解决方案的问题在于，只信任过一次的供应商仍然为您正在使用的系统提供源代码。他们仍然可以向构建器提供恶意源代码以供其构建和签名。我不知道支持者对这个问题的解决方案是什么，也许你信任的供应商不应该提供任何补丁、配置或任何系统软件。如果操作系统供应商不能实际修改或配置操作系统，那么坦率地说，这似乎不是一个有用的系统。也许有些人相信这个系统仍然是值得和可以实现的，但它显然不是一个简单的解决方案。出于这个原因，我认为对可复制构建的好处持怀疑态度是完全合理的，而且好处并不像支持者声称的那样明确。

问：与二进制文件相比，审计源代码更容易，这将使供应商更难隐藏恶意代码。

我不认为这是真的，因为“虫门”。缺陷门只是一个故意的安全漏洞，当供应商想要后门访问时，他们可以利用该漏洞进行攻击。对攻击者来说，防盗门的好处是它们完全可信地是可以否认的。如果有人抓到你，你可以简单地声称这是个错误，没有任何后果。然后你可以无限地重复这个广告，不断修正“错误”并不罕见，而且没有办法确定意图。如果有人想要提供恶意程序，可重复构建可以迫使他们同时提供源代码，但不能强制该程序是非恶意的，因此这并不是特别有用。您已经有能力信任源代码了。您可能会声称我没有数据支持这一点，但这就是攻击者的漏洞门的好处：永远不会有数据来证明您的错误行为。问：我

我们知道攻击者确实想危害构建基础设施，但更多的时候他们想要窃取必须通过构建服务器的专有源代码。这意味着供应商将增加真正发生攻击的可能性，以防止可能发生的攻击。这是一个重要的权衡，投资于可复制版本的决定并不像支持者声称的那样明显。问：如果用户选择信任一个所有二进制文件都必须由供应商共同设计的平台，但不信任该供应商，那么可重复构建允许他们验证该供应商是否是恶意的。

我认为这是一种幻想的威胁模型。如果用户确实发现供应商是恶意的，他们应该怎么做？

恶意供应商可以简单地拒绝向他们提供签名的安全更新，因此此威胁模型不起作用。

问：不可重现的构建违反了GPL，因为您不能从提供的源代码生成逐位相同的二进制代码。

我认为这个论点是荒谬的，这将意味着GPL二进制文件也不能使用代码签名或TLS。显然，供应商无法向您提供生成代码签名或CA根所需的私钥，因此根据此参数，它们也违反了GPL。

问：无论它对最终用户是否有用，它都将允许专家监控产生篡改构建的受损构建服务器。

我认为这是真的，但还有其他针对受损构建服务器的攻击，所有这些攻击都比生成被篡改的构建更常见。

更常见的情况是，攻击者想要签名密钥，这样他们就可以签名自己的二进制文件、窃取专有源代码、将恶意代码注入源代码tarball，或者将恶意补丁注入源代码存储库。可复制的构建对解决任何这些问题都无济于事。问：可复制的版本是高质量的版本。不管有没有安全福利，我只想让人们这么做。可重现的构建质量是否更好是一个见仁见智的问题，我们不应该试图通过声称这是为了安全而将我们的观点强加给别人。我碰巧不同意，我不认为可再现性会带来高质量的构建，我认为它会增加不必要的复杂性。