我想知道 Canonical（和/或 Debian）是否提供任何形式的保证，即主存储库和 Universe 存储库中的所有软件包都是总是由他们自己从源代码构建，或者由他们验证（在确定性或有符号可重复的构建），而不是仅仅包含其他人编译的二进制文件（这意味着你也必须信任他们，不要在他们的编译过程中做一些不光彩或不清楚的事情，或者使用除私钥之外的公共源代码库之外的任何东西进行签名（如果适用）。
Debian 和 Ubuntu 对此有何政策？他们有关于此事的官方页面或声明吗？我希望他们至少在主要版本中这样做，但 Universe 呢？当我从 Universe 安装某些东西时，我“信任”谁（提供他们声称已经编译的内容）？只是 Canonical/Debian 还是作者自己？
相关：（我在可重现构建中发现的一些信息，大部分是旧的）
答案1
main 和 universe 中的包是在 launchpad build farm 中从源代码构建的。您无需请求验证，因为您可以自己找到它。
例如，在撰写本文时，bind上传到 Ubuntu 20.04 LTS (Focal) 的最新构建版本是 1:9.16.1-0ubuntu2.5。您可以通过焦点改变公共邮件列表。具体来说这个帖子链接到发射台您可以在其中查看源文件和构建，以及每个受支持架构的构建日志。例如，可以找到该软件包该版本的 amd64 构建这里带有构建日志这里。
您可以对 Ubuntu 每个版本中的每个软件包重复此过程。
虽然我提到了 main 和 universe，但 restricted 和 multiverse 软件包也是如此，它们也是在 launchpad 上构建的。然而，它们可能包含非自由组件，因此不能保证“从源代码”构建，但每个软件包都有一个源代码包，即使它包含一些二进制组件。
答案2
从 Debian 的角度来看：所有软件包都在我们的专用服务器（buildd）上构建。未在 buildd 上构建的软件包不允许进入测试版并进入稳定版本。此外，自 2018 年左右以来构建的每个软件包都包含一个 .buildinfo 文件：虽然这不能保证可重现的构建，但它确实可以实现它们。Bullseye 中的所有软件包都有此文件，这要归功于 Debian 开发人员最近为触发很少更新的软件包（例如字体包）的重建所做的努力。
总体而言，Debian 的人们非常热衷于可重复构建，许多推动可重复构建的人都是该项目的一部分。构建可重复性的工具已集成到基础架构中：例如，软件包通常会使用标准化的时间戳来构建，并且很快就会使用标准化的位置来构建。
答案3
简单的答案是，Ubuntu 中的软件包始终基于 Ubuntu 自动构建器从档案中的源软件包构建而成。直到最近，Debian 才允许个人维护者构建的二进制软件包进入测试阶段并最终进入稳定阶段，但自从测试迁移重新开放进入靶心周期后，这种做法已不再被允许，但 Debian 开发人员仍然被允许（在某些情况下必须）将二进制软件包上传到不稳定版本。Ubuntu 对引入外部二进制文件的要求要严格得多。
然而，这个简单的答案仍然存在一些漏洞。
首先，没有技术手段可以保证源码包中使用的材料确实是源代码。事实上，这是不可能的，因为 Debian 社区对“源代码”一词的理解更类似于 GPL 定义而非传统定义，因此更多地取决于文件的创建和维护方式，而不是文件的格式。
其次，Debian 二进制包的内容不仅取决于源包，还取决于它所构建的环境。该环境是通过安装二进制包形成的。
这就给我们带来了一些问题，即某些程序需要自行构建。gcc、glibc、binutils、make 等需要 gcc、glibc、binutils、make 等。rust 需要 rust。freepascal 需要 freepascal。golang 通常使用 golang 构建（它声称也可以使用 gccgo 构建，但我尝试过，它实际上并没有起作用）。
大多数情况下，这是通过使用前一个版本来构建下一个版本来解决的，但有时会出现问题，并且无法以正常方式构建其中一个包，因为包的现有版本在一个或多个架构上存在太多问题。
有时维护人员会通过将引导二进制文件作为源包的一部分来解决这个问题。其他时候，存档中的包将使用手动构建的二进制包重新引导。在 Debian 中，这通常由开发人员简单地将二进制包上传到存档，然后上传源以强制重建自动构建器来完成。在 Ubuntu 中，我不确定具体过程是什么，但我知道只有相对较少的人有权限这样做。