Arch Linux

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

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

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

随着 7.0.0 版本的发布，pacman 增加了以单独的低权限用户身份来下载软件包的功能。

然而，对于使用本地仓库的用户，这可能意味着下载用户无法访问相关文件。要解决此问题，可以将这些文件和文件夹分配给 alpm 组，并确保相关文件夹设置了可执行权限（+x）。

$ chown :alpm -R /path/to/local/repo

请记得合并 .pacnew 文件以应用新的默认设置。

pacman 还引入了一个更改，以提高使用 .gitattributes 文件的 git 仓库的校验和稳定性。使用 git 源码的 PKGBUILD 可能需要一次校验和更改。

最近我们举办了项目负责人选举，前一任项目负责人 Levente “anthraxx” Polyák 再次参选，而没有别人参选。
因此根据选举规则他再任一届任期。
Arch Linux 项目负责人的职责包括作出一些决策（当没法达成共识时），处理和SPI相关的财政事务，以及整体的项目任务管理。
恭喜 Levente 并希望这一届任期也会是顺利的一届！🥳

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

大家可能已经听说了 [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)"

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

archlinuxcn 社区源的 keyring 包 archlinuxcn-keyring 由 farseerfc 的 key 签署验证，而 Arch Linux 官方 keyring 中包含了 farseerfc 的 key 。自12月初 archlinux-keyring 中删除了一个退任的 master key 导致 farseerfc 的 key 的信任数不足，由 GnuPG 的 web of trust 推算为 marginal trust，从而不再能自动信任 archlinuxcn-keyring 包的签名。

如果你在新系统中尝试安装 archlinuxcn-keyring 包时遇到如下报错：

error: archlinuxcn-keyring: Signature from "Jiachen YANG (Arch Linux Packager Signing Key) " is marginal trust

请使用以下命令在本地信任 farseerfc 的 key 。此 key 已随 archlinux-keyring 安装在系统中，只是缺乏信任：

sudo pacman-key --lsign-key "farseerfc@archlinux.org"

之后继续安装 archlinuxcn-keyring ：

sudo pacman -S archlinuxcn-keyring

我们很高兴地宣布 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 版本发布。

随着 shadow >= 4.14.0 更新， Arch Linux 的默认密码哈希算法由 SHA512 变更为 yescrypt。
另外，umask 配置现在需要在 /etc/login.defs 中配置而不是在 /etc/profile 中。
这个改动应该不需要用户作任何手动干预。

使用 yescrypt 的理由

我们选择了基于密码的密钥推导函数 (KDF) 和密码哈希方案 yescrypt，因为它被 libxcrypt 所采用 (已经可以在 libxcrypt 中使用，libxcrypt 由 pam 使用)，并且相较于 SHA512，yescrypt 对密码爆破有着更好的抵御能力。

虽然密码哈希竞赛的胜者是 argon2，但是这个算法目前还没有被 libxcrypt 采用 (第一次尝试，第二次尝试)。

配置 yescrypt

在 pam 实现对 /etc/login.defs 中的 YESCRYPT_COST_FACTOR 配置项的读取之前，该配置项没有任何作用。如果你需要为 YESCRYPT_COST_FACTOR 配置一个高于（或低于）默认值（5）的数值，那么你可以将其配置为使用 pam_unix 模块的 rounds 选项 （ 例如在 /etc/pam.d/system-auth 中）。

总体变更列表

• yescrypt 替代 SHA512 作为默认使用的密码哈希算法
• pam 会尊重在 /etc/login.defs 被选中的 ENCRYPT_METHOD 并且不会再覆盖被选中的方法
• filesystem (>= 2023.09.18) 和 pambase (>= 20230918) 中的改动确保了 umask 会在 /etc/login.defs 中被集中地配置而不再是在 /etc/profile 中

从 ansible-core 2.15.3 起，上游将文档和示例代码放到了单独的专用仓库 （参见相关变更记录）。
这意味着从 2.15.3 版本开始， ansible-core 包将不再打包文档和 /etc/ansible/ansible.cfg 下的默认配置样例。
关于文档，可以在线查阅：https://docs.ansible.com/
关于配置文件，如 wiki 上说明的，基本配置可以用以下命令生成：

ansible-config init --disabled > ansible.cfg

在从 <= 2.15.2-1 之前的版本升级到 2.15.3-1 之后版本的 ansible-core 之后，所有位于 /etc/ansible/ansible.cfg 的自定义全局 ansible 配置文件会变成 pacsave 文件。
要恢复它，请运行以下命令：

mv /etc/ansible/ansible.cfg.pacsave /etc/ansible/ansible.cfg

当从 budgie-desktop 10.7.2-5 更新到版本 10.7.2-6 时，需要用 magpie-wm 包替代 mutter43 包，前者目前依赖 mutter 包。因为 mutter43 和 mutter 冲突，必须手动干预以完成更新。
首先删除 mutter43 ，然后紧接着进行更新。请勿在这两个步骤之间重新登入或重启。

pacman -Rdd mutter43
pacman -Syu