Arch Linux 禁用 AUR 包接管

变更范围

• 讨论澄清，Arch 禁用的是对 被遗弃 的 AUR 包的接管，而不是 AUR 本身。
• 有些人指出，官方公告把这说成是一次进行中的事件中的临时暂停；也有人将其理解为目前实际上已被禁用。

AUR 的安全模型与风险

• AUR 被反复描述为一个不受信任的、“狂野西部”式仓库，区别于 Arch 的官方仓库。
• 从 AUR 构建本质上会运行由维护者控制的任意代码（PKGBUILDs），因此用户在安装前应当审查脚本。
• 许多人认为现实中的用户把 AUR 当作一等公民，往往跳过审查，这造成了巨大的攻击面，尤其是在 Arch/SteamOS 变得越来越流行之后。

被遗弃包的接管

• 初衷：让志愿者接手被放弃的包，避免名称污染，并保留流行名称（例如 foo 对比 foo-new、foo-legacy）。
• 批评者称，匿名用户单方面接管是供应链攻击和“身份洗白”的根本性、无法修复的载体。
• 另一些人认为，禁用接管是紧急止血措施；如果变成永久措施，AUR 会逐渐失去生命力，或者被迫重构。

建议的缓解措施

• 设想包括：恶意软件扫描（但对其有效性和可行性存在争论）、沙箱化构建、更强的账户控制，或某种形式的 KYC/真实身份信任链。
• 反对意见：扫描器只能发现已知恶意软件；严格身份要求会威胁匿名性，并可能带来法律/政治方面的负面影响。
• 也有人建议替代模式：用户自有仓库、作为跨发行版包管理器的 Nix，或 Gentoo 风格的社区 overlay。

更广泛的安全与文化争论

• 对桌面 Linux 相比 Windows 到底有多不安全存在分歧；官方仓库与用户仓库被明确区分。
• 讨论涉及黑客之间的“荣誉感”与逐利或国家支持的攻击者；几位评论者表示，一旦 Arch 变得流行，攻击始终是不可避免的。
• AI/LLMs 既被视为有助于审查 PKGBUILDs 的工具，也被视为降低编写恶意软件或生成不安全安装命令门槛的因素。

AUR 的未来

• 有人预测，禁用接管可能是弃用或彻底重构 AUR 的第一步。
• 也有人坚持，只要用户把 AUR 视为不受信任的代码、阅读 PKGBUILDs 并接受其固有风险，AUR 仍然有价值。