Flatpak 的未来发展方向
LWN.net News from the source
User: Password: | | Subscribe / Log in / New account
Flatpak 的未来发展方向
我们不擅长营销 我们承认，营销不是我们的强项。我们的优势在于撰写开发者、管理员和自由软件支持者赖以了解 Linux 世界动态的文章。请 立即订阅 以帮助我们继续这样做，这样我们就不用擅长营销了。 By Joe Brockmeier May 14, 2025 Linux Application Summit
在四月份的 Linux Application Summit (LAS) 上，Sebastian Wick 表示，从许多指标来看，Flatpak 的发展都很好。Flatpak 应用打包格式深受上游开发者和许多用户的欢迎。越来越多的应用程序在 Flathub 应用商店中发布，而且该格式甚至被像 Fedora 这样的 Linux 发行版所采用。然而，他担心 Flatpak 项目本身的工作已经停滞不前，除了基本的维护之外，有能力审查和合并代码的开发者太少了。
我无法亲自参加 LAS 或观看直播，所以我观看了 YouTube 上的 视频。幻灯片可以从 演讲页面 获取。Wick 是 GNOME Project 的成员，也是 Red Hat 的员工，他从事“各种桌面底层工作”，包括 Flatpak 和 desktop portals。
Flatpak 基础
Flatpak 最初由 Alexander Larsson 开发，他从 2007 年就开始从事类似的项目。第一个版本 是在 2015 年以 XDG-App 的形式发布。它在 2016 年更名为 Flatpak，这是对 IKEA 的 "flatpacks" 家具交付方式的致敬。
Flatpak 项目提供了 命令行工具，用于管理和运行 Flatpak 应用程序，用于 构建 Flatpak bundles 的工具，以及为 Flatpak 应用程序提供组件的 runtimes。Flatpak 项目使用 control groups，namespaces，bind mounts，seccomp 和 Bubblewrap 来提供应用程序隔离（“沙箱”）。 Flatpak 内容主要使用 OSTree 进行交付，尽管自 2018 年以来，一直 支持 使用 Open Container Initiative (OCI) images，并且 Fedora 将其用于 Flatpak 应用程序。 Flatpak 文档中的“Under the Hood”页面很好地概述了各个部分是如何组合在一起的。
发展放缓
Wick 在他的演讲开始时说，Flatpak 项目看起来一切都很好，但是如果深入研究，“你会注意到它不再被积极开发了”。例如，有人维护代码库并修复安全问题，但是“更大的更改实际上并没有发生”。他说，有很多针对新功能的合并请求，但是没有人觉得有责任审查它们，这有点问题。
缺乏审查员的原因是 Larsson 等关键人物离开了该项目。Wick 说，每隔一段时间，Larsson 可能会在必要时参与进来，但他基本上不是该项目日常开发的一部分。Wick 说，让新的 Flatpak 贡献者参与进来很困难，因为对重大更改获得反馈可能需要几个月的时间，然后再过几个月才能获得另一次审查。“这绝对不是让某人快速上手的好方法，也不是一个好的处境”。
“也许我抱怨的事情实际上并没有那么大的问题”，他说。Flatpak 运行良好；它可以完成它的工作，并且“我们只是使用它而没有过多考虑它”。从这个意义上讲，该项目处于一个良好的位置。但是他仍然一直在思考该项目如何“在约束下生存”，因为贡献者没有机会进入并进行更大的更改。
例如，Wick 说，Red Hat 一直在进行一项工作，该工作将允许将 Flatpaks 作为基本安装的一部分进行安装。供应商或管理员可以指定要安装的应用程序，而一个名为 flatpak-preinstall 的程序将负责其余的工作。该功能已经实现，并计划包含在 Red Hat Enterprise Linux (RHEL) 10 中。这项工作是由 Kalev Lember 和 Owen Taylor 在去年六月 开始 的，但是最初的 pull request 在二月份被 Lember 关闭，因为他离开了 Red Hat 并且不再从事这项工作。Wick 在二月份将其作为一个 新请求 拾起，但在五月初才进行了审查。
OSTree 和 OCI
Wick 的下一个主题是 Flatpak 中的 OCI 支持。尽管 OSTree 在某些方面取得了成功，并且仍在维护中，但它并未进行积极的开发。他指出，开发人员有一套“非常狭窄的工具”用于使用 OSTree，因此构建使用 OSTree 的 Flatpak 需要非标准和定制的工具，但是有一整套可用于处理 OCI 镜像的实用程序。更好的是，用于处理 OCI 镜像的工具“都是由我们以外的人开发的，这意味着如果我们接受它们，实际上不必做这项工作”。
不幸的是，有许多与 OCI 相关的改进再次等待审查以合并到 Flatpak 中。例如，Wick 提到 OCI 容器标准已添加 zstd:chunked 支持。与使用 gzipped tarballs 的原始 OCI 镜像格式不同，zstd:chunked 镜像使用 zstd 压缩，并且具有 skippable frames，其中包括其他元数据（例如目录），从而允许文件级别的重复数据删除。简而言之，zstd:chunked 允许仅拉取自上次更新以来已更改的那些文件，而不是在更新容器镜像或 Flatpak 时拉取整个 OCI 层。
Taylor 从 2023 年 9 月提交了一个 pull request，该请求将为 Flatpak 添加对 zstd 压缩层的支持。从那时起，它几乎没有受到关注，并且“目前只是坐在那里”。
缩小权限
Flatpak 的关键功能之一是沙箱化应用程序并限制它们对系统的访问。Wick 说，该项目已经添加了功能来“缩小”沙箱并提供更受限制的权限。例如，Flatpak 现在具有 --device=input，允许应用程序访问输入设备而无需访问所有设备。
他说，这样做的一个问题是，系统中安装的 Flatpak 可能不支持较新的功能。用户的 Linux 发行版可能仍在提供较旧版本的 Flatpak，该版本不支持 --device=input，或者 Flatpak 开发人员可能希望使用的任何新功能。Wick 说，需要有一种方法让应用程序默认使用新的权限，但如果在具有较旧版本的 Flatpak 的系统上使用，则回退到较旧的权限模型。
他说，这并不是一个全新的情况。“我们之前在 Wayland 和 X11 上也有过这种情况”，即如果系统正在运行 Wayland，则 Flatpak 不应绑定挂载 X11 套接字。现在，与 用于 USB 访问的 xdg-desktop portal 也有类似的情况，该 portal 在 2021 年 添加 到 xdg-desktop-project。对该 portal 的支持在经过多次迭代后于 2024 年 合并 到 Flatpak 中。缺少的是指定向后兼容权限的能力，以便可以使用较新版本的 Flatpak 为 Flatpak 应用程序提供 USB 访问权限 (--device=usb)，并在必要时保留 --device=all 权限。同样，有一个 pull request（来自 Hubert Figuière）实现了这一点，但 Wick 说“它也只是坐在那里”。
Wick 还希望改进 Flatpak 处理音频访问的方式。当前，即使主机系统使用 PipeWire，Flatpak 仍然使用 PulseAudio。这样做的问题是 PulseAudio 将对扬声器和麦克风的访问捆绑在一起 - 您可以同时访问两者，也可以两者都不访问，但不能只访问一个。因此，如果应用程序有权播放声音，它也有权捕获音频，Wick 有些轻描淡写地说，这“不太好”。他希望能够使用 PipeWire，后者可以公开对仅扬声器的受限访问。
Wick 说，一直以来令人头疼的一件事是嵌套沙箱在 Flatpak 中不起作用。例如，应用程序无法在 Flatpak 内部使用 Bubblewrap。许多应用程序（例如 Web 浏览器）大量使用沙箱。
他们真的很喜欢将他们的选项卡放入自己的沙箱中，因为事实证明，如果其中一个选项卡正在运行某些设法利用并突破该进程的代码，至少它会被包含并且不会传播到浏览器的其余部分。
目前，Flatpak 所做的是拥有一个应用程序可以调用并生成另一个可以进一步限制的 Flatpak 实例的侧面沙箱。“因此，从这个意义上讲，这是一种解决问题的方法，但它也有点脆弱”。他说，这种方法已经存在问题很长时间了，但是没有人知道该如何解决它们。
理想情况下，Flatpak 只需支持嵌套命名空间和嵌套沙箱，但是目前它不支持。 Flatpak 使用 seccomp 阻止沙箱中的应用程序直接访问用户命名空间。有一个 API 可用于创建子沙箱，但它的限制更多。他说，对用户命名空间的限制已经过时了：“长期以来，公开用户命名空间并不是一个好主意，因为它向用户空间公开了一个很大的内核 API，可能会被利用”。Wick 认为，如今，用户命名空间是一个经过充分测试且广泛使用的接口。他不认为再反对用户命名空间有什么好的理由。
xdg-dbus-proxy
Flatpak 应用程序不直接与 D-Bus 通信。而是，flatpak-run 为每个 Flatpak 实例生成一个 xdg-dbus-proxy，它“不完全在同一个沙箱中，基本上只是在旁边”。代理负责根据在使用 flatpak-run 启动应用程序时处理的规则设置过滤。设置代理时，Flatpak 首先从 deny-all 状态开始，然后添加允许的特定连接。这是为了使应用程序不会公开其他应用程序不应该使用的内容。
Wick 说，他希望将过滤从 xdg-dbus-proxy 直接移动到 D-Bus 消息代理，并提供基于 cgroups 路径的策略。这不是已经实现的事情，但是他说他计划在 busd 中开发一个原型，busd 是用 Rust 编写的 D-Bus 代理实现。
这也将允许更动态的策略，这将允许应用程序即时将服务导出到其他应用程序。当前，策略是在运行 Flatpak 时设置的，并且无法在之后进行修改。
顺便说一句，这意味着 Flatpak 应用程序无法通过 D-Bus 相互通信。它们仍然可以与其他应用程序通信；例如，Wick 说，应用程序可以通过主机的共享网络命名空间进行通信，“这意味着你可以使用 HTTP 或任何东西，如果你愿意，可以使用成千上万的侧通道”。
Flatpak 的网络命名空间“有点难看，我真的没有一个好的解决方案”，Wick 说，但是他想指出该项目应该关注这一点。“例如，你在本地主机上绑定了一些东西，突然所有应用程序都可以访问它”。他举了 AusweisApp 的例子，这是一个德国 ID 的官方身份验证应用程序，可用于通过政府网站进行身份验证。它在本地主机上公开了一项服务，这使得系统上的所有 Flatpak 应用程序都可以使用它。
这就是我认为我们真的需要关注的一些东西。我不确定这是否可以直接利用，但至少有点可怕。
Wick 说，该项目需要为 Flatpak 应用程序创建一个网络命名空间，“但是我们周围没有任何网络专家，这有点尴尬，我们真的必须找到一个解决方案”。
他说，该项目发现自己所处的另一个尴尬之处是 NVIDIA 驱动程序。该项目必须为支持的多个运行时构建多个版本的 NVIDIA 驱动程序，这给用户带来了巨大的网络开销，他们必须下载每个版本 - 即使他们不需要所有驱动程序。（Linux Mint 论坛上的这个抱怨 很好地说明了这个问题。）这也意味着打包为 Flatpaks 的游戏需要根据新的运行时不断更新，否则它们最终将停止工作，因为它们的驱动程序停止更新并且游戏将不支持当前的 GPU。
Wick 的建议是从 Valve Software 那里获得启发。他说，Valve 使用类似于 Flatpak 的模型来运行其游戏，但是它使用主机系统中的驱动程序并在游戏的沙箱中加载所有驱动程序的依赖项。Valve 使用 libcapsule 库来执行此操作，该库“有点脆弱”并且难以确保其运行良好。他希望静态编译驱动程序并在所有 Flatpak 应用程序之间共享它们，而不是使用 libcapsule。这目前只是在想法阶段，但是 Wick 说他希望最终解决驱动程序问题。
Portals
Portals 是 D-Bus 接口，提供诸如文件访问、打印、打开 URL 等 API。 Flatpak 可以授予沙箱化应用程序访问 portals 的权限以进行 D-Bus 调用。Wick 指出，portals 不是 Flatpak 项目的一部分，但是它们对它至关重要。“我们对 portals 所做的任何事情都会直接改善 Flatpak，我们需要改进很多 portal 相关的东西”。
他举了 Documents portal 的例子，该 portal 使沙箱外部的文件可供 Flatpak 应用程序使用。 Documents portal 非常适合共享单个文件，但对于其他应用程序（例如 Blender、GIMP 或音乐应用程序）来说，它过于精细且具有限制性，这些应用程序可能需要访问整个文件库。“你需要在某个时候为文件提供更粗粒度的权限模型”。他说，有一些可能性，例如将用户选择的主机位置绑定挂载到沙箱中。
Wick 有许多他希望看到的用于实现 portals 的想法，例如支持自动填充密码、Fast Identity Online (FIDO) 安全密钥、语音合成等。他承认，现在编写 portals 的代码“有点困难”，但是通过使用 libdex 可以使其更容易。（有关 libdex 的简要介绍，请参见 Christian Hergert 的 博客文章。）他说，甚至可以考虑用 Rust 重写东西。
Flatpak-next
假设在未来十年，没有人再从事 Flatpak 的工作。Wick 说，“如果你可以重写 Flatpak，你会怎么做？我认为我们应该去的愿景是几乎所有东西都使用 OCI”。Larsson 在创建 Flatpak 时的选择在当时是好的和合理的技术决策，但是它们最终“不是每个人都拥有的东西”。这是一个问题，因为只有少数人了解 Flatpak 的作用，并且该项目必须自己完成所有事情。
但是，他说，如果该项目“所有东西都使用 OCI”，它将免费获得很多东西，例如 OCI 注册表和工具。然后，它只是归结为 flatpak-run 必须做什么，而那不会很多。他说，使用现代容器工具重新思考 Flatpak 并与更广泛的容器生态系统保持一致将使一切变得更容易，并且值得探索。他再次提出了使用 Rust 进行重写的想法。
问答环节
在 Wick 的会议结束时，有一点时间可以提问。第一个问题是，如果该项目转向 OCI 工具，现有的 Flatpaks 会发生什么情况。“我是否需要直接丢弃 [应用程序] 并再次下载，还是说这太遥远了，你还没有考虑过？”Wick 说，这在客户端会是一个问题，但是 Flathub（例如）具有其 Flatpaks 的所有构建说明，并且可以简单地重新构建它们。
另一位听众担心使用容器基础设施。他们说，存储镜像的 OCI 注册表缺少 GNOME Software 等应用程序用于 Flatpaks 的索引和元数据。确保他们可以保留相同的用户体验的前进方向是什么？Wick 说，现在有一个标准可以在 OCI 注册表中存储非镜像，这将允许存储“我们目前为 Flatpak 存储的相同内容”，但是编写代码并将其合并将是困难的部分。
最后一个问题是关于是否有任何具体计划关于直接将 PipeWire 与 Flatpak 一起使用而不是 PulseAudio 路由。Wick 说，他一直在与 PipeWire 的创建者 Wim Taymans 讨论如何在 Flatpak 中添加对它的支持。他说，这主要是关于“添加 PipeWire 策略，以便在它知道它是一个 Flatpak 实例时做正确的事情”。
Index entries for this article
Conference| Linux Application Summit/2025
to post comments
Ran into a problem...
Posted May 14, 2025 20:29 UTC (Wed) by ccchips (guest, #3222) [Link] Linux Mint 22.1 had jellyfin in software manager, but only as a flatpak. After several hours of headaches, I removed the flatpak version and then installed from jellyfin website with their apt repository. I think distributions ought to offer both flavors of packages whenever possible. There was quite a bit of cleanup after I removed the flatpak version, which wanted to install the whole jellyfin system in my home folder.
OCI signing?
Posted May 14, 2025 20:56 UTC (Wed) by DemiMarie (subscriber, #164188) [Link] (1 responses) Will OCI support signed flatpaks? If not, that is a dealbreaker for security-sensitive users.
OCI signing?
Posted May 15, 2025 10:50 UTC (Thu) by swick (subscriber, #110059) [Link] For downloading, sure, that can work the same way as with ostree remotes. Tying it into the kernel doesn't really work with current flatpak because everything just becomes part of an ostree repo locally.
OCI zstd
Posted May 14, 2025 23:02 UTC (Wed) by tianon (subscriber, #98676) [Link] (7 responses)
the OCI container standard has added zstd:chunked support Just to be clear, the OCI has standardized support for zstd in general, but the clever zstd:chunked tricks are a podman-ecosystem specific format (that any zstd implementation should be able to handle reading, due to the way it hides the extra data in the chunking).
OCI zstd
Posted May 14, 2025 23:35 UTC (Wed) by vasi (subscriber, #83946) [Link] (6 responses) Wow, reading the code this format is fascinating and weird. Tar-headers converted to JSON, compressed, and stored in a skippable frame! Interesting that this is done at the file-level, rather than just using rsyncable-mode for zstd.
OCI zstd
Posted May 15, 2025 15:39 UTC (Thu) by nliadm (subscriber, #94000) [Link] (5 responses) "Rsyncable" output (as I understand it) is mostly about making sure rsync's blocking and the compressor's output line up as much as possible. For example