8 月 23 日晚上，aur-general 邮件列表里出现了一则报告：AUR 软件包 xsnow 及其 -bin 变体的安装脚本，正在从 Tor 网络下载一个名为 systemmanager 的不明二进制文件。半小时内就有维护者指出，这不是普通的恶意提交，而是一条蠕虫——如果另一位 AUR 维护者在自己机器上安装了这个包，脚本会借他的手继续扩散到其他 AUR 仓库。Arch 邮件列表又过了不到一小时，处理报告的受信任用户确认：两个包已回滚，涉事账号被停用并移出共同维护列表。
反应不算慢。但这个场景本身就是过去三个月的缩影：从 5 月底开始，Arch 最大的社区软件源 AUR 持续被恶意提交试探，而 Arch 团队不得不一次次给这套靠志愿者自治运转了近二十年的体系打补丁。对一个软件源几乎完全依赖社区自治的发行版来说，这不是一次普通的安全事故，而是对整个治理模式的压力测试。
九十天：攻击是怎么逼 AUR 关闸的
把时间线拉平，节点其实很清晰。
5 月底，browsh-bin 包出现首个被确认的恶意提交，试图引入可疑的 NPM 依赖，被维护者发现后回滚、账号停用。同期还有 gnome-randr-rust 等包中招。5 月 28 日，开发者 Pierre Chapuis 给出了一个影响后续所有决策的判断：攻击主要靠"收养"（adoption）得手——恶意账号申请接管长期无人维护的包，一旦获批就能合法推送更新，问题不在账号被盗，所以光上两步验证挡不住。Arch 邮件列表6 月 12 日，Arch 官方发布新闻确认 AUR 正在经历活跃的恶意软件包事件，并对注册、推送和收养做了限制。Arch Linux 官网据社区文章梳理的时间线，7 月 30 日收养功能被关闭，8 月初 git 推送也一度冻结，AUR 事实上进入了只读状态，处置进展都通过 aur-general 邮件列表发布，并被社区广泛转述。知乎
重开，但换了一套规则
8 月 11 日，aurweb v6.5.0 部署上线，SSH/git 推送和收养功能重新开放。Arch 邮件列表但回来的不是原来的 AUR，而是一套新规则：
收养不再是先到先得：每个收养申请现在需要 Package Maintainer 人工审核，每个包同一时间只能有一个待处理申请，14 天无人处理自动拒绝。Arch 邮件列表
注册仍未开放：存量未验证账号 7 天后收到警告、14 天后删除，官方说法是在为后续接入 SSO 登录做准备；
推送恢复，但所有包的变更历史都保留在 git 里，回滚成为标准处置动作。
代价同样立竿见影。8 月 13 日就有维护者在邮件列表抱怨：审核人力没跟上，收养申请卡着不动，连"包已过期"的标记都无人应答。Arch 邮件列表闸口收紧和流程通畅之间的平衡，到现在还在调。
对多数 Arch 用户来说，日常环境就是一个桌面加几个终端窗口，fastfetch 报出机器里几百上千个包，其中从 AUR 装的那部分，从来是最不让人放心的。入口倒是没变：无论用 yay、pikaur 这类命令行助手，还是图形化软件管理器，AUR 依然是那个随手就能装软件的来源。变的只是这道门后面的安检。
志愿体系付出的真金白银
也是在这三个月里，志愿者一侧出现了肉眼可见的损耗。
8 月初，Arch 开发者、在安全方向工作近十年的 Morten Linderud（社区 ID Foxboron）宣布卸任包维护者。Arch 邮件列表他没有任何公开表态把离开和这次事件挂钩，但时间点恰好落在 AUR 治理压力最大的区间。他留下的 mkinitcpio——负责生成安装和更新时 initramfs 的关键组件——和 arch-install-scripts 一度成了无人认领的孤儿包。8 月 11 日，Robin Candau 宣布 ArchWiki 管理员 nl6720 接任 mkinitcpio 维护，关键组件没有断档。Arch 邮件列表
但剩下的孤儿包谁来接？8 月 21 日有人在邮件列表问，普通人能为 AUR 安全做点什么。回答很直白：目前只有 Package Maintainer 能处理 AUR 上的各类请求；至于 RFC 0019 提出设立专职 AUR 审核员的方案，“还不知道什么时候”。Arch 邮件列表
现在用 AUR，值得做的三件事
对天天要用 AUR 的人来说，最直接的变化是：别再闭眼 -Syu 了。
这一轮攻击的载荷几乎都藏在安装脚本和构建文件的改动里。知乎Arch 官方在 6 月的公告里也给了同样的建议：更新 AUR 包时，复查所有 PKGBUILD 和安装脚本的改动。Arch Linux 官网用 pikaur、yay 这类助手更新时，打开"更新前查看 build files diff"的选项；用图形管理器的，更新前也多看一眼变更内容。重点核对三处：source 的下载地址有没有换、校验和有没有变、package() 函数或 .install 安装文件里有没有多出来的命令。
另外值得把自己机器上从 AUR 装的包过一遍清单，尤其是两类：直接执行上游二进制的 -bin 包，以及已经孤儿化、长期没更新的包。顺手去 AUR 页面看一眼最近的提交记录，成本不高。还有一个简单的观察信号：如果你装过的包突然更换了维护者，先别急着更新，看看新维护者的动静。
值得继续盯的几个信号
接下来一段时间，有几件事值得留意：RFC 0019（AUR 审核员角色）的时间表，它决定了深夜再出恶意包时谁来处置；注册通道什么时候、以什么形式重开；积压的孤儿包和收养申请能不能被新的审核流程消化；以及会不会再出现类似的蠕虫——xsnow 事件已经证明，攻击路径正在从"接管老包"转向"感染维护者"。
Arch 背后没有公司，AUR 的安全本质上是志愿者用时间换来的。过去三个月证明的是：光靠善意不够；现在正在证明的是：规则可以为善意重写。对用户的建议就一句：继续用，但多看一眼。
