我使用 Debian Jessie，Debian repo 有很多开源包。我知道有一个过程会在它们在存储库中使用之前对其进行检查。
虽然我知道不可能找到每个错误（例如，heartbleed），但我想知道是否会发生对应用程序的某种审查。例如，如果密码管理器出于“统计目的”将每个保存的密码发送到中央服务器。在一个不起眼的错误和公然的恶意软件之间有很多中间立场，我想知道在哪里（如果有的话）画出适合回购的线。
该审查可能不一定会阅读每一行源代码，但可能会检查应用程序是否未意外连接到奇怪的服务器，或将纯文本文件写入磁盘，或任何恶意软件类型的行为。
所以我的问题是：开源应用程序在被存储库接受之前要经过什么过程？
（为了避免 XY 问题：我问是因为我想从 repo 安装密码管理器，并且我想相信它不会在后台泄露我的密码）
在哪里（如果有的话）画出适合回购的线。
这可能看起来令人沮丧，但其中很多只是常识。也就是说，如果没有人报告问题，那么一切都会好起来的。
这并不像一开始听起来那么糟糕。有很多阶段有人可以报告问题。要了解这些事情是如何完成的（并让您相信这些信息不仅仅是表面上的价值），让我们来看看在某些 Linux 发行版上将包放入官方存储库的过程。尽管那里有几十个发行版，但我们几乎只有三个主要的基础存储库，其他发行版从中提取自己的存储库：
让我们看一下每个模型使用的阶段，以及检查这些包的额外工作量。但首先是一些普遍的担忧：
许多人使用的软件（我的意思是很多人，例如httpd）也由许多人维护。这样的环境将首先具有编码审查和报告试图破坏代码的用户的方式。
此外，在许多人使用的软件中，CVE 猎手（例如，当时碰巧研究该软件的研究人员）会在数小时内捕获一个故意的恶意软件。
除了可能查看软件本身源代码的人之外，发行版还为每个软件包提供软件包维护者。如果一个不可靠的功能被推送到一个软件的代码存储库中，并且发行版中该软件包的软件包维护者注意到了它，他将报告它（而不是更新他在发行版中的软件包）。
此外，在极其乐观的情况下，将一个软件的新版本添加到存储库中（需要编译和功能测试）需要 20-30 小时（我最近看到的最好的是 Vim 8，添加到 Arch repos 需要 17 小时正式发布后）。如果在下一个版本中存在由故意破坏引起的已知 CVE，包维护者将不会更新存储库中的包（在任何发行版中）。
Debian 有debian 测试和 debian 不稳定，Debian 用户可以（并且经常这样做）使用不稳定的软件包。Debian 不稳定版最常被软件包维护者逐个软件包使用。Debian 测试被希望更快地获得最新软件的人们广泛使用。Debian 建议，debian 测试中的软件包通常不像启用了安全更新的稳定版本那样安全。
极其关键的软件（例如httpd或openssl）会受到额外的审查。Debian 开发人员的安全团队会检查最重要的软件包（没有检查每一行代码，但会进行大量检查）和几乎所有的 CVE。他们的错误跟踪器在查找和修复问题方面非常有效。
另外，我知道 Debian 安全团队中至少有一名成员在某些软件包上运行CBMC 编译器。
在 RedHat（和类似发行版）中包含软件包是通过使用开放发行版作为测试场来执行的。对于 RedHat，这就是 Fedora。但这并不是说可以简单地将软件包添加到 Fedora。相反，对要包含的软件包进行了大量审查：Fedora 的包装指南是彻底的。
还有更多，在进入 RedHat 的 repos 之前，一个包必须在 Fedora 主 repos 中表现良好，但要进入 Fedora 主 repos，包应该首先在 EPEL repos 中。并且 EPEL 存储库也根据包指南进行审查。
这是上述两者的混合。要进入 Arch 上的主仓库，包必须在AUR上表现良好（并且很受欢迎） 。
然而，有一个CVE 社区安全团队，就像在 Debian 中一样。
因此，该软件包在其社区的开发阶段进行检查。如果社区很小（比方说，只有作者），第二个看到它的人将是发行版上的包维护者。如果单个包维护者或社区成员对更改提出危险信号，则很可能会落入安全团队（或 CVE 猎人）的手中并得到处理。
所有这些似乎仍然很粗略，因为它取决于人们报告的事情。然而，如果你从统计学上考虑，攻击一个由 3 个人使用的包裹几乎没有什么好处。为数百万人使用的软件包添加一个狡猾的代码更改将是有利可图的，但它需要通过数百人的审查。让一个人阅读进入发行版的每一行代码在确定安全漏洞方面可能不如当前使用社区眼睛有效。
真正的危险在于特定于语言（且独立于操作系统）的存储库：类似于pip(python)、gem(ruby) 甚至 CPAN (perl)。确实有人在看里面的包，但是你可以在那里发布一个包含恶意软件的包，它可能会被忽视好几天。
这确实是一个 XY 问题。
为避免密码管理器泄露您的密码，您可以使用 AppArmor 配置文件拒绝网络访问。
其他答案指出，存储库控制侧重于功能，而不是漏洞或后门。创建 AppArmor 配置文件是一种更强大的控制。
Debian 政策手册是有关 Debian 软件包的所有问题的首选资源。
根据Debian 自由软件指南，Debian 有一个严格的政策，要求 main 和 contrib 中的所有软件包都是“自由软件” 。开源但不符合 DFSG 的软件被分离到非自由存储库中，该存储库必须由用户明确启用。
Debian 政策手册要求官方存储库中的所有软件包“不得有太多错误以至于我们 [Debian 开发人员] 拒绝支持它们”。这是相当模糊的，但本质上它是这样编写的，只有当维护者愿意花费非凡的精力来解决这些问题时，它才允许有错误的包。
许多重要的包也是使用可重现的构建过程构建的，以确保您安装的编译后的二进制包与它声称来自的源代码相匹配。
Debian 可能拒绝将软件包包含在其存储库中的原因有很多。在大多数情况下，软件包可能由于 Debian 开发人员提出的任何原因而被拒绝，但大多数软件包由于许可问题或与 dpkg 不能很好地配合使用（例如无法干净卸载的软件包）或失败遵循质量政策（例如，具有良好的包描述、手册页、遵循标准文件系统层次结构）。如果软件包未能引起 Debian 开发者的兴趣，它也可能被隐式拒绝。
意外连接到奇怪的服务器
由于 Debian 软件包必须符合 DFSG，这要求源代码是开放的，所以真的没有“意外”行为。由于源代码是开放的，因此您可以合理地争辩说，源代码中清楚写的所有内容都“不出所料”。因此，这给我们留下了意外/未记录后门的混淆实现，而不是微不足道的恶意软件。
一些高质量的 Debian 软件包也可能附带 AppArmor 配置文件，这可以在一定程度上限制这些应用程序中的意外行为。