LWN: Fedora将缺省提供debuginfod！-技术圈

关注了就能看到更多这么棒的文章哦～

Enabling debuginfod for Fedora by default

By Jake Edge
April 14, 2021
DeepL assisted translation
https://lwn.net/Articles/852416/

4 月初，Fedora 项目经理 Ben Cotton 发布了一项建议，在 Fedora 35 中缺省使用 Fedora 的 debuginfod 服务器。debuginfod 目的是帮助开发者用各种工具调试或追踪那些缺乏必需的源代码和调试符号的程序。服务器可以根据需求来直接向工具提供这些数据。但在默认打开这个功能之前，有一些安全和隐私问题需要解决。

实际上，这个功能所需的源代码和调试信息 Fedora 早就已经具有了，但是存放在 debuginfo 和 src RPMs 中，必须先被安装上，之后才能被调试工具访问到。这些 RPM 文件相当大，比起用户在追踪、调试过程中可能想看的那少数几个文件的符号表文件以及源代码文件来说，要大得多。此外，通过 DNF 安装它们的话还需要 root 权限，而用户可能不具备这种权限。debuginfod 功能所提供的一个非常有价值的服务，就是只根据合适的时机，以及用户的权限，来抓取必需的那一小部分数据。

2019 年 10 月的一篇 Red Hat 博客文章描述了 debuginfod，并指出它是 elfutils 工具中即将出现的一个新功能。它的背后想法是，GCC 和 LLVM 会在 object 文件中存储的 Build.ID hash 值可以用来识别对应的是哪个版本的符号表和源代码。Build.ID 是在 2007 年被添加到 Fedora 8 中的。Build.ID 可以直接根据 object 文件找出对应的调试符号表，并且源代码路径也存储在 object 文件中，也可以用来识别（并提供出）正确的源代码包。

2020 年 10 月，Frank Ch. Eigler 在 fedora-devel 邮件列表中发布了关于 debuginfod 功能和相应的测试服务器的说明。他想了解一下大家是否有兴趣在 Fedora 建立自己的服务器：

问题是 Fedora 本身并没有运行一个这样的服务器，而我们的测试服务器只能承载 debuginfo/debugsource rpms 以及 architectures 代码和符号表的一个子集。所以，Fedora 的开发者、用户无法获得所有信息，或者说，无法从官方渠道获得。我想知道现在是否是时候该建立这样的一个服务器了。如果大家有兴趣的话，我可以开始跟 Fedora 的基础设施人员讨论具体细节。

总体反应是很积极的，这也引出了在 Fedora 35 版本中设置 DEBUGINFOD_URLS 环境变量的提议，以便在需要调试信息的时候可以使用新的 Fedora debuginfod 服务器。正如该功能提案者 Eigler 所指出的，在 debuginfod.stg.fedoraproject.org 有一个暂存服务器（staging server），所以 Fedora 用户已经可以开始尝试了：

[……]大多数工具已经可以支持它了，试试吧。
% export DEBUGINFOD_URLShttps://debuginfod.stg.fedoraproject.org/
不久之后，所有的 F32+软件包/版本/架构都可以通过这种方式进行调试。

一旦这个暂存版本的服务器确实流行起来，那么就会把数据转移到正式的生产环境服务器 debuginfod.fedoraproject.org 上去，这也是 DEBUGINFOD_URLS 在 Fedora 35 中的缺省设置。总的来说，使用暂存服务器的效果很好，尽管 Michael Catanzaro 对它的性能有点担心：

我昨天开始测试暂存服务器。它看起来有点慢——我担心有人调试关于 WebKit 的东西会怎么样，在桌面版上这个可能会很常见——但除此之外它工作得非常好。印象很深。非常棒。

Owen Taylor 指出，该功能也适用于 Flatpak 的应用程序。Eigler 解释说，Catanzaro 看到的一些性能问题可能是因为暂存服务器在从 Fedora Koji 构建系统中来 pull RPM 文件引起的。在这个过程中确实有一些无法避免的延迟，当然使用缓存可能有帮助：

在从一些大 rpm 中寻找新文件的情况下，在解压（CPU 密集型的操作）、将选出的文件保存到临时磁盘（RAM/storage 密集型的操作），然后将文件发送给你（网络密集型的操作），这些方面确实会有一些延迟。
在服务器上，有一些预取/缓存配置选项，可以利用 fedora-infra 提供的功能强大的服务器。
在客户端也会积极进行缓存，对文件有为期一周的保留时间。

David Malcolm 有点担心 debuginfo 的 python 代码中用到的一些 Python 程序。早在 2010 年，在 Fedora 13 版本中，他就已经添加了这些程序，是用来协助在 GDB 对 Python 调试。但他对自动安装这些程序感到担心：

我对通过这种服务来提供 python 脚本感到紧张，因为比起 DWARF 格式来说，坏人利用 python 脚本做坏事的门槛要低得多，所以也许如果人们想要.py 文件，他们必须以传统的方式安装调试信息包？（在 rpm 文件中实际上也是.py 文件，但与手动安装 debuginfo rpms 相比，如果自动下载这些 py 文件而不给用户参与的机会，似乎可能会导致麻烦）。

Eigler 说，debuginfod 没有办法为.py 程序单独做什么，但如果大家认为重要的话，可以后面增加一个处理。他指出，数据的出处本身是为了提供安全保证的：

[……]我不确定被破坏的 DWARF 在本质上是否比被破坏的 Python 代码更安全。但所有这些都是基于这样一个前提的：文件来自一个普遍受信任的构建系统、提供了受信任的产物、由受信任的人维护。如果有恶意的文件进来，那么这个服务质量就会被降低，并且（或者）客户会受到影响。

类似地，Björn Persson 指出，该提案缺乏对各种安全和隐私问题的处理。该提案确实提到了在 2 月份宣布为 Debian 提供 debuginfod 服务后，Debian 用户提出的一些隐私问题，但也指出 openSUSE Tumbleweed 默认启用了该功能（2020 年 2 月），"我们没有听到说有什么争议"。如果本地系统缺乏适当的文件，那么当前在调试的文件的 Build.ID 和源文件名就会被泄露给服务器。Debian 在安装时增加了一个提问，来决定是否启用该功能。

除了隐私问题外，Persson 还希望该提案能解决服务器的安全问题：可能会有什么样的攻击、如何验证从服务器收到的文件，以及对文件做什么样的签名和认证。Eigler 感谢他的问题，并在提案的在线版本中增加了一个 "安全常见问题（Security FAQ）" 部分，对 Persson 的问题进行了初步解答。

正如大家也想到的一样，攻击范围在很大程度上取决于使用这些数据的工具、工具具有什么权限、稳健性、以及被调试程序有些什么权限。对于从服务器上提供的信息并没有增加特别的验证。正如 Eigler 对 Python 的回应所指出的，这一切都归结为对发行版的信任，以及对 HTTPS 的信任。正如 FAQ 中所说：

Debuginfod 服务器对原版发行版中的数据原样提供出来，并通过 HTTPS 安全地传输。在 Fedora 中没有每个文件的签名的底层机制，那么 debuginfod 也没有必要添加一个。因此，除了浪费带宽再下载相应的签名后的档案并进行比较外，没有任何其他机制可以手动验证这些文件。客户端代码将对文件权限采取一些基本措施，以减少发生意外改动的风险。原则上，如果收到的文件被篡改，那么同样的篡改者也可以扰乱用户的调试工具，甚至接管账户。

这个功能有许多好处，比如可以让那些无法使用 DNF 来安装调试符号表 package 的用户更方便，以及与通常相当大的调试信息包相比，可以大大减少需要发送和存储的数据量。debuginfod 服务器只发送用户当前调试任务所需的部分内容，而不会发送整个 package 的所有相关源代码和调试信息。

虽然可能需要为管理员增加一个明确的选项来禁用（或选择不使用）debuginfod 服务器，但 Fedora 35 似乎极有可能默认使用它们。同时，用户现在已经可以通过适当地设置 DEBUGINFOD_URLS 环境变量来开始查询服务器。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～