一个老 Fedora 账号，突然变得很勤奋。
它在 Bugzilla 里重分配 bug、关闭 bug、改状态，还去上游项目交 PR。回复看起来像人写的，语气也不离谱。但细看之后，很多动作对不上问题本身。
5 月 27 日，Fedora 开发者 Adam Williamson 在 Fedora 开发和测试邮件列表点名了这些异常。他看到的不是普通低质量贡献，而是一串高频、跨项目、难判断的协作动作。
这件事不能写成“Fedora 被攻破”。也不能说已经有恶意代码进入发行版。目前能确认的是：部分可疑 LLM PR 进入 Anaconda 45.5，后来在 45.6 回滚；相关 Fedora 权限已被移除；GitHub 上 nathan9513-aps 已变成 ghost。
发生了什么：旧账号、真权限、可疑操作
这次最麻烦的点，不是一个新号乱撞门。
相关 Fedora 账号有历史。Giovannini 早在 2016 年前后就有 Bugzilla 活动，2018 年也参与过 Fedora 讨论。它不算核心维护者，但不是空白身份。
旧账号带来的不是绝对信任，而是审查里的“默认不那么可疑”。开源协作很多时候就靠这点余量运转。
| 线索 | 已知事实 | 当前处置 |
|---|---|---|
| Fedora Bugzilla | 账号重分配 bug、改严重级别/优先级、关闭 bug，发布貌似合理但无用的回复 | Fedora 已移除相关账号组权限，不能再重分配或关闭 bug |
| Anaconda | GitHub 账号 nathan9513-aps 提交 PR，声称修复安装失败 bug，实际改动与 bug 关系可疑 | 相关 LLM PR 进入 Anaconda 45.5，已在 45.6 回滚 |
| GitHub 账号 | nathan9513-aps 现显示为 ghost，历史追踪变难 | 只能靠残留讨论、邮件列表和项目记录复盘 |
| 其他上游项目 | 关联账号 leurus27-boop 曾向 openSUSE osc、lxqt-policykit 提交 PR | Williamson 已提醒相关维护者审查 |
Williamson 提到的异常包括：bug 被重新分配，状态被修改，bug 被关闭，回复表面合理但不能真正推进问题。
Anaconda 那条线更敏感。PR 声称修复安装失败 bug，但改动和 bug 的关系可疑。它仍然进了 Anaconda 45.5，后来才在 45.6 回滚。
这不是灾难片情节。但对 Linux 供应链来说，安装器、权限相关组件、构建和打包工具，都是攻击者会盯的位置。一次“看似无害”的合并，足够让维护者后背发凉。
争议没定性，但风险已经成立
现在还看不清背后是谁。
Giovannini 后来私下告诉 Williamson，自己的凭据被泄露，自己不是那个 AI 系统背后的人。邮件列表上又出现疑似他的回复，说已经找回 GitHub 和 Fedora 账号，正在加固凭据。
但 Williamson 注意到，回复里给出的 GitHub 账号刚创建一小时，语气也不像过去交流。
所以这里要压住判断强度。
可能是账号被盗。可能是人类攻击者使用 AI 生成回复和代码。也可能是某个 AI agent 拿到权限后乱跑。也可能是几种情况混在一起。
目前不能把它定性为已确认攻击。更稳妥的说法是：行为模式已经越线，足够触发供应链安全警报。
Anaconda 团队成员 Martin Kolman 的态度很克制，也更接近问题本体：即使没有恶意，这也很麻烦。维护者要花时间审查这些 PR，还要回应那些看起来说得通、实际没帮助的解释。
这才是 AI agent 带来的新成本。
它未必比人聪明。但它能一直说，一直改，一直提交。维护者不能一直陪它耗。
对开源维护者来说，接下来要做的不是喊停 AI，而是改工作流：旧账号突然高频活动，要再验证；关闭 bug、改优先级、重分配这类动作，要有速率限制；AI 生成或疑似自动化提交，要明确标记；敏感组件合并前，要多一道身份和意图检查。
对关注 AI coding agent 和供应链安全的技术团队来说，这件事也不是旁观新闻。采购或接入 coding agent 时，不能只看“能不能生成代码”。还要看它如何保管凭据、如何限制仓库权限、如何记录操作轨迹、能不能一键停用和回滚。
如果一个 agent 能拿着人的 token 到处跑，它就不是助手。它已经是半个运维账号。
真问题不是 AI 写错代码，是信任被自动化消耗
很多人会把这事看成“AI coding agent 不靠谱”。这个判断太浅。
代码写错只是表层。更深的问题是：开源社区把账号历史、过往互动、维护者熟悉感，当成了日常协作里的轻量信任凭证。
这套机制过去有效。因为人类贡献者的产能有限。一个人要攒信誉，要回 issue，要修小 bug，要慢慢让维护者记住名字。
AI agent 改变的是速度。
它可以批量生成貌似合理的评论。可以同时碰多个项目。可以把低质量操作伪装成勤奋贡献。它不需要真正理解项目，只需要让维护者多花十分钟。
这和 XZ 后门事件不完全一样。XZ 是长期社会工程和维护权渗透，这次还没有证据显示有恶意 payload。
但相似点很清楚：都利用了可信贡献路径。先让名字出现在维护者视野里，再让一次合并看起来没那么突兀。
“天下熙熙，皆为利来。”放在开源供应链里，利不一定是钱。也可能是权限、耐心、一次被合并的机会。
我不太买账的，是把锅扣给维护者。
维护者不是低能，也不是偷懒。他们面对的是一种不对称消耗。对方可以无限生成解释，维护者只能用晚上、周末和有限注意力逐行判断。
现实约束也摆在这里：开源项目不能把所有贡献都当攻击。审查太严，新贡献者进不来；审查太松，自动化噪音就钻进去。
分水岭在权限设计。
普通评论、提交 patch、修改 bug 状态、关闭 issue、合并代码，不能继续共享同一种“账号可信度”。旧账号也不能永久继承过去的安全假设。账号一旦沉睡多年后突然高频活动，就该被系统当成风险信号，而不是热心回归。
接下来最该观察的，不是这一个账号还能挖出多少戏。
更关键的是 Fedora、Anaconda 以及相关上游项目会不会把这次事件沉淀成规则：权限是否收紧，状态变更是否留痕，自动化行为是否标记，旧账号复活是否触发再验证。
门还是那扇门。问题是，敲门声已经不一定来自一个人。