受信任的更新渠道与挠痒痒

自由软件的一大优点是人们可以轻松地获取实用程序或库,并按照他们认为合适的方式对其进行定制。任何人都可以提交错误修复或改进,并且可以在许多人、项目和组织之间轻松共享。对于像 Python 的 pypi 这样的分发系统,有一个更新通道,受信任的维护者可以发布修复程序,以便库的使用者可以轻松获得更新。在谈到更新渠道和代码时,不可避免地还要谈到人和信任。一个关键部分是使用者和维护者之间的信任关系。理想的软件分发系统将是软件维护人员和每个最终用户之间的盲目、可信赖的管道。

由于我们讨论的是代码库,因此自然关系与信任关系不同:它是在消费者和库本身之间,而不是维护者之间。我使用 Requests 来处理 HTTP,而不是 @nateprewitt 的复刻。我的 setup.py 包含对 'requests' 的引用,而不是对我信任的保持库更新的维护者的引用。

有一些案例是依赖库被并被用于分发恶意软件。或者在另一个案例中有人提出接管一个流行的库,然后将恶意软件插入其中。如果维护者太轻易将库交给其他人,那么这将被滥用。如果它们太难移交,那么许多有价值的库将被放弃或分叉。必须检查分叉给库使用者增加了额外成本,因此理想情况是总有一个值得信赖的维护者。

对于像 Requests 这样的大型项目或像 Debian 这样的发行版,有一个过程可以确保新的维护者做正确的事情。还有很多非常有价值的小型库。例如,apache_log_parserpymtp。在这些情况下,与库作者投入的整体努力相比,通过适当的流程将其移交给新的维护者的成本是相当大的。或者它可能是由现在被其他工作缠身的单一维护者维护。

在 F-Droid 中,审查应用合并请求,即 fdroiddata,也是审查信任关系是否发生变化。这建立在确保新代码正常工作、确保其仍然是自由软件以及所有负面特征都已正确标记的基础之上。正确进行此审核非常重要,尤其是当你考虑到在 F-Droid 中,许多应用会自动更新而不需要核心贡献者对其进行审核。

所有开发者都必须在软件开发过程中的多个关键点考虑这些信任问题,包括:

  • 将库添加到任何软件时
  • 帮助新的维护者接管现有软件
  • 审查对源代码存储库 URL 的更改

还有一些关于如何更好地将我们需要信任的人映射到包含软件的过程的想法。一个有趣的例子是 Rust 生态系统的 cargo-crev。它提供了一个描述和加密链接受信任的开发者及其对软件包的审查的系统。