Arch Linux

我们想提醒大家 rsync 发布了安全版本更新 3.4.0-1 ，已经在公告 ASA-202501-1 中所描述。
攻击者仅需要 rsync 服务器的匿名读取权限，比如公共镜像站，就可在服务器端的机器上执行任意代码。并且，攻击者可以控制受影响的服务器端，然后在连接上该服务器的客户端读写任意文件。据此可以获取敏感信息，比如 OpenGPG 和 SSH 的私钥，并且可以通过写入 ~/.bashrc 或 ~/.popt 文件的方式执行恶意代码。
我们强烈建议所有在执行 3.4.0-1 之前版本的 rsync 守护进程或者客户端的用户立刻升级系统并重启。以及因为 Arch Linux 镜像站通常使用 rsync 同步更新，我们强烈建议所有镜像站管理员立刻行动，即便这些镜像站中提供的包文件本身是被加密签名保护的。
所有 Arch Linux 维护的基础设施服务器和镜像服务器已经更新修复。

以前 Arch Linux 打包用的源码（比如PKGBUILD文件）一直没有写明协议，这潜藏着问题。明确指定协议可以澄清这种不确定性。
根据 RFC 40 我们同意把所有打包用的源码授权为非常开放的 0BSD 协议。这项变更不会限制你能用打包源码做的事情。请参阅 RFC 以了解缘由和之前的讨论。
在做出变更之前，我们想给贡献者一个提出反对声音的渠道。从2024年11月19日起，为期一周时间，贡献者们将收到一封邮件通知，其中会列出他们所做的所有贡献。

• 如果你收到邮件并且同意这次变更，那么不需要你那边进行任何操作。
• 如果你不同意，那么请回复邮件，然后我们会一起协商一个方案。

如果你之前为 Arch Linux 打包做出过贡献但没有收到邮件通知，请联系我们 package-sources-licensing@archlinux.org 。

2024-09-14更新：该问题已经通过更新 gcc 到包含修复的提交的方式得到解决。Arch Linux 的官方包（链接到更新后的 gcc-libs 者）将不再受影响。

由于在 2024b 版本中，tzdata 使用了暂不受支持的一些新格式，可能会造成 libstdc++ 及其他库无法正确解析。出现的错误现象可能是部分使用 C++ 编写的软件（如 waybar）无法识别和使用除了 UTC 以外的所有时区。

为了避免这个问题，目前可以将 tzdata 包降级到（或保留在）2024a-2 版本。

相关链接：Arch tzdata的错误报告、上游 tzdata 的讨论、libstdc++ 上的更改。

在更新到 openssh-9.8p1 之后，现存的 SSH 守护进程将无法再接受新的连接（详见 https://gitlab.archlinux.org/archlinux/packaging/packages/openssh/-/issues/5 ）。
如果从远程更新系统，请确保在更新后立刻使用 systemctl try-restart sshd 命令重启 sshd 服务。
我们在评估是否可能在今后 openssh-9.8p1 的打包中加入更新时自动重启 sshd 服务的机制。

系统参数 vm.max_map_count 的默认值将从 65530 增加到 1048576 。
这一变更应该能对一些内存需求较高的应用程序帮助改善性能，减少崩溃或者启动问题，尤其是（但不仅限于）通过 Wine/Steam Proton 玩一些 Windows 游戏的情况。总体上来说，用户应该得到更平滑的开箱使用体验，而目前没有已表明的潜在顾虑，参见 arch-dev-public 邮件列表上关于本提议的讨论。
这项对 vm.max_map_count 的修改将会增加到 2024.04.07-1 版本的 filesystem 包，并且将在更新后生效。
在更新系统前，如果你已经在 sysctl.d 文件中自己设置过这个参数，请要么删除它（来切换到新的默认值），要么确保你的配置文件会比 /usr/lib/sysctl.d/10-arch.conf 文件有更高的优先级（以覆盖新的默认值）。

简单讲：立即升级系统和容器镜像！

大家可能已经听说了 [1]，xz 上游发布的 5.6.0 和 5.6.1 版本的代码包（tarball）中含有添加后门的恶意代码。

Arch Linux Security Tracker 记录了该漏洞 [2]。

xz 软件包旧于 5.6.1-2 的版本（即 5.6.0-1 和 5.6.1-1）包含该后门。

以下发布内容（release artifacts）也包含了受影响的 xz 版本：

• 安装镜像：2024.03.01 版
• 虚拟机镜像：20240301.218094 和 20240315.221711 版
• 容器镜像：任何 2024-02-24 到 2024-03-28 之间（包括这两个日期）构建的版本

受影响的发布内容已经从我们的镜像站上移除。

强烈建议不要使用受影响这些受影响的发布内容。请下载当前的最新版本！

升级系统

如果你的系统当前安装了 xz 5.6.0-1 或 5.6.1-1，强烈建议你立即进行完整系统升级：

pacman -Syu

升级容器镜像

要确定否正在使用受影响的容器镜像，使用以下命令（podman 用户）：

podman image history archlinux/archlinux

或者（docker 用户）：

docker image history archlinux/archlinux

所有旧于 2024-03-29 且新于 2024-02-24 的 Arch Linux 容器镜像都受到了影响。

使用以下命令升级受影响的容器镜像到最新版本（podman 用户）：

podman image pull archlinux/archlinux

或者（docker 用户）：

docker image pull archlinux/archlinux

升级之后，请确保重新构建基于受影响版本的任何容器镜像，并检查所有运行中的容器！

sshd 认证绕过 / 代码执行问题

根据上游报告 [1]：

openssh 不直接使用 liblzma。但 debian 和其他几个发行版对 openssh 打了补丁，引入了 systemd 通知支持，而 libsystemd 确实依赖于 lzma。

Arch 并不直接将 openssh 链接到 liblzma，因此这种攻击途径是不可能的。可以通过以下命令来确认这一点：

ldd "$(command -v sshd)"

但是，出于谨慎，我们建议用户通过升级系统/容器镜像移除恶意代码 —— 因为可能有其他还没有被发现的后门利用方法。

伴随 mkinitcpio v38 发布，几个之前以 Arch 打包提供的挂钩（hook）移动到了 mkinitcpio 上游项目中。这些挂钩是： systemd, udev, encrypt, sd-encrypt, lvm2 和 mdadm_udev。
为了保证不破坏用户设置，我们在相关包中加入了一些临时的冲突，避免安装不再相互兼容的包。
以下这些包必须同时更新：

• mkinitcpio 38-3
• systemd 255.4-2
• lvm2 2.03.23-3
• mdadm 4.3-2
• cryptsetup 2.7.0-3

请注意 mkinitpcio 的 --microcode 选项和 preset 文件中的 microcode 选项将被弃置，取而代之的是新的 microcode 挂钩。这可以让你删掉引导配置中的 initrd 加载微码的行，因为它们现在已经打包进了主 initramfs 镜像文件中。

为了提高性能、可靠性以及与 systemd 的集成，我们将 dbus-broker 设为 D-Bus 的默认实现。
在可预见的未来，我们仍将支持使用 dbus-daemon，即之前的实现。Pacman 会询问你是否要安装 dbus-broker-units 或 dbus-daemon-units。我们建议选择默认选项。
如需了解更详细的原因，请参阅我们的 RFC 25 。

我们很高兴地宣布 bugtracker 到 GitLab 的迁移已经完成！🥳

感谢每个在迁移过程中提供了帮助的人。

这意味着 GitLab 上的软件包仓库的 issue tracker 和 merge request 现在已经被启用了。

在此之后，旧版的 bugtracker 将会被关闭。但是出于归档相关的原因，我们会为其提供一份静态副本，如此，链接（比如这个随机选取的 Task #56716）将会保持稳定可用。被迁移的 bug 的评论区会留有一个关闭评论区的评论，该评论会提供一个指向 GitLab 的新 URL。

软件包的打包 bug 现在在对应软件包的打包资源仓库中创建。archlinux.org 的软件包页面上的 “Add a new Bug” 按钮现在将会自动将你引导到正确的地方去创建 issue。在此之后，工作流基本上和原先的一致。首先，我们的 Bug Wrangler 们会查看并分类 issue，然后它们将会被交由对应的 Package Maintainer 们去处理。一个完整的 issue 列表可以在这里找到。

如果你没有一个（授权认证了我们的 SSO 服务的）GitLab 帐号的话，你可以像 banner 中建议的那样使用你想要的用户名来写一份邮件发送到 accountsupport@archlinux.org。

我们将为我们的发行版中的 JDK/JRE 包引入一个改动。这个改动是由较新版本的 Java (> 9) 的 JRE 构建方式导致的。我们将在 Java 21 版本中引入这个改动。

总的来说，我们将会让 JDK 和 JRE 包冲突，而不再是允许它们在系统中共存。JDK 包已经包含了运行 Java 应用所需的运行时环境，所以如果你同时需要 Java 的运行时环境和编译环境的话，以后你只需要安装 JDK 包即可。如果你只需要 Java 的运行时环境的话，那么 JRE (或 jre-headless) 就足够了。

这可能需要由用户在系统升级时进行手动干预：

• 如果你同时安装了 JDK 和 JRE，那么你可以使用 pacman -Syu jdk-openjdk 命令来手动安装 JDK 并同时删除 JRE 相关的包。
• 如果你同时安装了 JRE 和 JRE-headless，那么你将会需要手动选择二者中的一个并手动安装它，因为这两个包现在会互相冲突。
• 如果你只安装了 JDK/JRE/JRE-headless 中的一个，那么 pacman 应该可以在不需要用户手动干预的情况下自行解析依赖。

目前，这些内容仅针对即将到来的 JDK 21 版本发布。