返回资讯中心
外部精选
软件工程
#开发者实时流

421个曾停滞的关键开源仓库半年后恢复活跃,部分靠AI编程助手提交代码

来源标题:Weekend at Bernie's II

421个在5月处于停滞或不明状态的关键开源仓库在半年后重新活跃。近四分之一恢复活跃的仓库中,提交历史里出现了AI编程助手的记录,且多数提交来自仓库自己的核心贡献者。

Hacker News 最新jamietanna2026/11/7 · 今天26 分钟阅读

以下正文由 AI 翻译自 Hacker News 最新(原文版权归原站所有),可能存在偏差,重要内容请以原文为准。

六个月过去了,你的哪些依赖还在戴着墨镜?

2026年11月6日 开源 安全 维护者

“Weekend at Bernie's”事件六个月后,五月份处于死亡、休眠或未知状态的421个关键仓库重新活跃起来。在1993年的续集里,Bernie被一场出了点差错的巫毒仪式复活,结果变成了一具听到音乐就会动起来的尸体。在近四分之一的复活仓库中,音乐以编码代理的形式出现在提交历史里,其中大多数提交来自仓库自己的头号提交者。

在上一篇文章中,我把ecosyste.ms关键包背后的仓库分成了四类,后续文章梳理了一个项目走向死亡的各种方式: 在上一篇文章中,我预测AI辅助的漏洞发现即将考验那些安静的项目:“针对其中任何一个项目的首份安全报告,就是那场考验。”我在11月初用同一个分类器重新跑了同样的流水线,主要的分组结果与五月相差不到两个百分点: 用五月的分类器跑十一月的数据只改变了23个分组,所以变化来自仓库中的活动,加上较旧的issue和release退出一年的时间窗口。421个仓库从休眠、死亡或未知变为活跃,而五月处于活跃、休眠或未知状态的295个仓库现在已死亡。

421个复活仓库中,只有16个的包在注册表维护者列表上发生了变化。对照提交历史检查,其中一个是改名的账号,七个是在Docker和Google等组织内部轮岗的员工,还有两个添加了此后没有任何提交的账号,剩下六个是真正由新人接手了工作。其余405个仓库的注册表维护者列表没有变化。大多数注册表的废弃包政策都是围绕把死包转让给新所有者来设计的,这是项目易手的少数途径之一,而这些复活项目中所有权变更很罕见。

为了看看这些回归的维护者在用什么工具,我对416个托管在GitHub上的复活仓库的每一次提交运行了CHAOSS的披露工具,覆盖自去年十一月以来的一年,这与我在八月对整个关键集合所做的测量相同。它会匹配co-author trailer、代理机器人邮箱、代理分支名和类似信号,所以这些数字是下限。

在五月之前的六个月里,这些仓库中人类撰写的提交有3.3%带有AI披露,分布在22个仓库中。在那之后的六个月里,这一比例是7.9%,分布在95个仓库中,共778次提交,其中566次来自各仓库自己的头号提交者,通常带有Claude Code trailer。死亡和未知类复活仓库中每一笔披露的AI提交都发生在五月之后,47个死亡仓库中有10个、64个未知仓库中有8个出现了这类提交。

复活仓库中代理使用最重的包括: 我对这些提交日志的解读是,代理把一个已完成但被忽视的库上积压的工作缩小到了可以清理的程度,而那些已经熟悉代码的维护者最适合检查代理产出的内容。运行扫描还发现了该工具检测中的两个缺口,我已经为两者提交了修复。

自五月以来,有43个复活仓库的维护者发布了针对自己代码中漏洞的修复。在维护者同时发布了仓库安全公告的情况下,20个中有19个在修复版本发布后一天内上线,而等待发生在之后,即公告在GitHub队列中等待审核进入全球Advisory Database期间: GitHub在六月写过关于积压的文章。私有漏洞报告从一月的每周约550份增加到五月大部分时间的每周3000多份,并且“自四月中旬以来,由于这波激增,我们一直未能持续达到内部的发布目标。”

在自五月以来同时有仓库公告和有日期修复的1,011份公告中,修复版本与维护者公告之间的中位间隔在每个分组中都是零天。从那里到经审核数据库的中位等待时间,对于五月活跃的仓库是11天,对于休眠、死亡或未知的仓库是38天。Dependabot和npm audit读取的是经审核的数据库,所以在等待期间,复活包的用户收不到任何警报,尽管修复版本和维护者公告都是公开的。

GitHub表示会按“项目影响和严重程度”优先审核。此前不活跃的仓库在每个严重程度区间都等待更久,它们六月发布的十份公告平均等待了81天,而同月发布的活跃仓库公告为17天。总共只有20份公告,其中五份来自crass,所以这是一个模式而非证据,我的猜测是,一个仓库沉寂多年的包在项目影响上得分很低。

43个修复中有六个在发布说明、分支名或提交中可以看到AI工具: 在五月处于未知状态的1,086个仓库中,有189个此后收到了外部issue或PR,这就是上一篇文章描述的测试。其中94个有维护者关闭或合并了某些东西,另有17个有维护者提交而外部条目未获回应。其余78个没有维护者活动,转入了死亡分组。在五月处于休眠状态的1,171个仓库中——我在上一篇文章中将其标记为更大的担忧——107个现在已死亡,310个活跃,大约每出现一个新死亡就有三个复活。

五月到十一月间,该集合中的包共发布了1,345份公告,五月活跃的仓库中有8.5%至少获得一份,而休眠和死亡仓库约为1%,未知仓库为0.3%。这些比率统计的是已公开的报告,而一份公开公告需要有人接收私有报告、编写修复并在发布的同时发布公告。发送到无人看管仓库的私有报告,只有报告者自己发布才能进入公告数据库,所以死亡仓库上的低比率并不能很好地衡量它们收到了多少报告。

(原文较长,此处译出前 6000 字,完整内容请点「打开原文」。)

正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。

打开原文
去社区讨论 →