默认情况下，如果我尝试使用 GUIX 安装软件包并且它不能逐位重现，会发生什么情况？
我非常担心 2024 年包管理器的状况（以及供应链攻击的风险）。虽然传统的包管理器喜欢apt和yum由专门的包管理器团队维护，他们验证、测试并以加密方式签署所有版本，新的包管理器如扁平包装,折断，并且docker允许随机用户提交包，并且将愉快地下载并运行恶意修改的软件。
今天我了解了 GUIX，它强调可重现的构建。但是在花了一个小时阅读他们的文档之后，我无法确定 GUIX 中的可重现构建是如何工作的——也不知道它是否是这样的。强制执行对于所有包。
GUIX 的默认安装是否要求构建可重现？它如何确保软件和生成的二进制文件的真实性？该系统可能存在哪些漏洞？
答案1
默认情况下，如果我尝试使用 GUIX 安装软件包并且它不能逐位重现，会发生什么情况？
没什么特别的，软件包已安装。
但是，如果您实际尝试并重现该包，并且 GUIX 源包生成的内容与相应 GUIX 二进制包中的内容不同，那么您就会敲响警报。
GUIX 包管理器通过提供一个独特的功能来自动执行此操作，从而使这一切变得容易：guix challenge命令。
然而，建设一切从源头验证其可重复性是极其乏味的，如果您运行 20 个系统的队列，您可能不想将每个包构建 20 次：相反，您可以将每个系统设置为在不同的包集上运行挑战，并行验证。
或者，如果您不是那么顽固到挑战每个软件包，您可能会找到一些可靠的 GUIX 用户，并且当他们说他们已经挑战了特定软件包并发现它们可以重现时，大多数人都相信他们的话。也许你还会时不时地随机挑战一些包裹，让诚实的人保持诚实。如果有足够多的人这样做，任何不可重复性都会很快被发现，同时工作量也会被分担。
换句话说，它落到你根据您可用的计算资源和所需的警惕级别来决定挑战哪些数据包以及挑战的频率。
另外，请记住，仅可再现性并不能保证不存在恶意代码：如果没有人读取实际的源代码，邪恶的人可能会设法将邪恶代码注入 GUIX 源代码存储库，并最终获得完全可再现的邪恶二进制包。