自动生成 · 5 篇文章 · 按热度排序
数据源：官方 HN Firebase API
[1] Mythos Finds a Curl Vulnerability
Mythos Finds a Curl Vulnerability · 615票 · 252评论 · by Daniel Stenberg
来源：daniel.haxx.se · HN讨论
标签：安全, curl, 漏洞, Mythos, AI安全
背景注释： curl (由 Daniel Stenberg 开发的命令行 HTTP/FTP 客户端/库) | Daniel Stenberg (curl 创始人，Haxx 创始人，开源安全重要人物) | Mythos (Anthropic 开发的 AI 安全研究系统) | 漏洞猎人 (使用 AI 自动发现开源软件漏洞的新兴领域)
一句话介绍
Anthropic 旗下被宣传为"危险地好"的 AI 安全扫描模型 Mythos 对 curl 进行了代码审计，最终仅发现一个低危漏洞。curl 维护者 Daniel Stenberg 指出，此前多种 AI 工具已发现约两三百个 bug，Mythos 并无显著优势，认为炒作主要是营销；但他也强调 AI 代码审查工具整体确实比传统工具强大，建议所有项目都采用。
原文完整中文翻译
Mythos 在 curl 中发现了一个漏洞
是的，只是一个，即 singular "one"。
2026年4月，Anthropic 引发了大量媒体噪音，当时他们得出结论：他们新的 AI 模型 Mythos 在发现源代码中的安全漏洞方面"危险地好"。显然 Mythos 在这方面表现如此出色，以至于 Anthropic 不会向公众发布这个模型，而是将其限量提供给一些精选公司一段时间，让一些优质客户（？）先行一步，在普通大众拿到它之前先修复最紧迫的问题。
全世界似乎都失去了理智。这是世界末日的开始吗？这无疑是一场非常成功的营销恶作剧。
我的（非）访问
Anthropic 与"Glasswing 项目"合作的一部分内容是，Anthropic 还通过 Linux 基金会向"开源项目"提供访问其最新 AI 模型的渠道。Linux 基金会让他们旗下的 Alpha Omega 项目处理这部分，而我被他们的代表联系上了。作为 curl 的 lead developer，我很荣幸地获得了访问这个神奇模型的资格并欣然接受了邀请。当然，我想看看它能在 curl 中发现什么。
我签署了获取访问权的合同，但之后什么也没发生。数周过去了，我被告知某处出了点问题，访问被延迟了。
最终，有人提议说，其他拥有模型访问权限的人可以代表我使用 Mythos 对 curl 进行扫描和分析，并将报告发送给我。对我来说，这个区别并不重要。我不会有太多时间去探索各种不同的提示词并做深入研究。无论谁来运行它，能让工具生成一份合格的初步扫描和分析报告就很好了。我愉快地接受了这个提议。
（我有意省略了完成 curl 分析的个人身份，因为这不是这篇博文的主题。）
AI 对 curl 的扫描
在收到这份首个 Mythos 报告之前，我们已经使用多种不同的强大 AI 驱动工具对 curl 进行了扫描（我是说"除了"持续运行大量"普通"静态代码分析器、使用最严格的编译器选项、以及多年模糊测试之外"）。主要是 AISLE、Zeropath 和 OpenAI 的 Codex Security 被用于通过 AI 严格审查代码。这些工具及其分析在过去 8-10 个月左右的时间里触发了大约两到三百个错误修复被合并到 curl 中。其中相当一部分由这些 AI 工具报告的发现已被确认为漏洞，并被发布为 CVE，可能有十几甚至更多。
如今，我们还使用 GitHub Copilot 和 Augment code 等工具来审查 pull requests，它们的意见和投诉帮助我们提交更好的代码并避免合并新的 bug。我的意思是，我们当然仍然会合并 bug，但 PR 审查机器人会定期高亮显示我们修复的问题：如果没有它们，我们的合并会更糟。AI 审查是"附加"于人类审查之上的。它们帮助我们，而不是取代我们。
我们还看到大量高质量的安全报告汹涌而来：安全研究人员现在广泛而有效地使用 AI。
安全对我们 curl 项目来说是"头等大事"。我们遵循每一条指导方针，并正确地进行软件工程，以减少代码中的缺陷。扫描缺陷只是保持这艘船安全的众多步骤之一。你需要非常努力地寻找另一个在软件安全方面做得与 curl 一样多或更多的软件项目。
保持 curl 安全的步骤
2026年5月6日
我们怀着极大的期待收到了由 Mythos 生成的首份源代码分析报告。这是我们又一次找到需要改进的地方和修复 bug 的机会。打造一个更好的 curl。
这次初步扫描是在 curl 的 git 仓库及其 master 分支的某个特定 commit 上进行的。它统计了 src/ 和 lib/ 子目录中分析的 178K 行代码。
该分析详细说明了它执行搜索的几种不同方法和手段，以及它如何专注于尝试找出哪些缺陷。报告顶部有一条有趣的注释：
"curl 是现存被 fuzz 测试和审计最多的 C 代码库之一（OSS-Fuzz、Coverity、CodeQL、多次付费审计）。在热路径（HTTP/1、TLS、URL 解析核心）中找到任何问题的可能性很小。"
……它正确地在这些区域没有发现任何问题。
Mastodon 上一个完全非科学的投票，关于人们对 Mythos 扫描 curl 的期望
curl 的规模
curl 目前在排除空行的情况下有 176,000 行 C 代码。源代码由 660,000 个单词组成，比小说《战争与和平》英文版的全部内容多 12%。
平均而言，curl 中每一条生产源代码行都已经被编写（然后重写）了 4.14 次。我们对此精雕细琢。
此刻，仍然保留在 git master 中的现有生产代码由 573 个不同的人创作。随着时间的推移，共有 1,465 个人到目前为止在 curl 的 git 仓库中提交了他们的更改并被合并。
到目前为止，我们已经为 curl 发布 188 个 CVE。
curl 被安装在超过 200 亿个实例中。它运行在超过 110 个操作系统和 28 种 CPU 架构上。它运行在地球上的每一部智能手机、平板电脑、汽车、电视、游戏机和服务器中。
五个发现变成了一个
报告得出结论，它发现了五个"已确认的安全漏洞"。我认为当 AI 自信地说出这个结论时，使用"已确认"这个词有点好笑。是的，AI 认为它们是已确认的，但 curl 安全团队的观点略有不同。
五个问题感觉不算什么，因为我们原本期待的是一份很长的清单。一旦我和我的 curl 安全团队成员对这些短清单进行了数小时的深入研究和细节挖掘，我们就把清单缩减到一个被确认的漏洞。另外四个中，有三个是误报（它们高亮显示的缺点在 API 文档中有记录），第四个我们认为是"只是一个 bug"。
这个被确认的漏洞将成为一个低危 CVE，计划与我们在 6 月底待发布的下一个 curl 版本 8.21.0 同步发布。这个缺陷不会让任何人感到呼吸困难。所有这些漏洞的细节当然不会在那之前公开，所以你需要在公布细节之前耐心等待。
Mythos 关于 curl 的报告还包含一些被发现的 bug，报告认为这些不是漏洞，就像任何新的代码分析器在你对数十万行代码运行它时会做的那样。报告中的所有 bug 都在被调查，我们一个一个地修复那些我们认同的 bug。
总的来说大约有二十个被描述和解释得非常清楚的 bug。几乎没有误报，所以我猜他们的确定性阈值相当高。
curl 肯定因此变得更好，但要按发现的问题数量计算，我们之前使用的所有 AI 工具都产生了更多数量的 bug 修复。这当然是很自然的，因为我们运行的首批工具已经有了更多更容易发现的 bug。随着我们一路修复问题，发现新问题逐渐变得更难了。此外，bug 有大有小，所以仅比较数字并不总是公平的。
并非特别"危险"
然而，我的个人结论只能是这样：到目前为止，围绕这个模型的大量炒作主要是营销。我没有看到证据表明这个设置在发现问题上比 Mythos 之前的其他工具更高明或更高级。也许这个模型稍微好一点，但即使有，也不会有好到在代码分析方面产生显著影响的程度。
这只是其中一个源代码仓库，也许它在其他方面要好得多。我只能对我看到的发现发表看法和评论。
仍然非常好
但请允许我强调并重申我之前说过的话：AI 驱动的代码分析器在发现源代码中的安全缺陷和错误方面明显比以前任何传统代码分析器都要好。所有现代 AI 模型现在都在这方面做得很好。任何有时间且有一些实验精神的人现在都可以找到安全问题。高质量的混乱是真实的。
任何尚未使用 AI 驱动工具扫描其源代码的项目，很可能会使用这新一代工具发现大量缺陷、bug 和可能的漏洞。Mythos 会做到，其他许多工具也会。
不在你的项目中使用 AI 代码分析器意味着你给对手和攻击者留出了时间和机会，让他们去发现和利用你找不到的缺陷。
AI 分析器有何不同
它们可以发现注释中说的与代码实际做的之间的矛盾，然后得出代码没有按注释所述工作的结论。
它可以检查我们无法运行分析器的平台和配置的代码
它"知道"第三方库及其 API 的细节，因此可以检测滥用或错误假设。
它"知道"curl 实现的协议的细节，可以质疑代码中似乎违反或矛盾协议规范的地方
它们通常善于总结和解释缺陷，这是旧式分析器相当繁琐和困难的事情。
它们通常可以生成并提供一个补丁来修复它发现的问题（即使补丁通常不是 100% 的修复）。
报告的更多细节
零内存安全漏洞被发现。
方法论说明：本次审查是由 LLM 子代理进行并行文件读取的手动驱动分析，每一个候选发现在被记录之前都会在主会话中通过直接源代码检查进行重新验证。CVE 到变体追踪的映射是从 curl 自己的 vuln.json 构建的。没有使用自动化的 SAST 工具。
这一结果与 curl 作为最被 fuzz 测试和审计最多的 C 代码库之一的状态一致。防御性基础设施（到处使用的受限动态缓冲区、curlx_str_number 在每个数字解析上都有明确的 max、curlx_memdup0 溢出保护、CURL_PRINTF 格式字符串强制、每个协议的响应大小上限、pingpong 64KB 行限制）系统性地关闭了在这个规模的代码库中通常会产生效果的 bug 类型。
覆盖范围现在包括：所有小协议、所有文件解析器、所有 TLS 后端的验证路径、http/1/2/3、ftp 全深度、mprintf、x509asn1、doh、所有认证机制、内容编码、连接重用、会话缓存、CLI 工具、平台特定代码，以及 CI/构建供应链。
AI 发现已知类型的错误
应该指出的是，AI 工具找到的是我们已知的那种通常的错误。它只是找到了新的实例。
到目前为止，我们还没有看到任何 AI 报告一种全新或完全不同类型的漏洞。它们不会以那种方式重塑这个领域，但它们确实比以前的任何工具挖出了更多问题。
更多待发现
这些绝不是最后一个要发现或报告的 bug。就在我写这篇博文草稿的过程中，我们已经收到了更多来自安全研究人员关于疑似问题的报告。AI 工具将进一步改进，研究人员可以找到新的不同方法来提示现有的 AI，使它们发现更多问题。
我们还没有走到这条路的尽头。
我希望我们能继续用 Mythos 和其他 AI 对 curl 进行更多扫描，一次又一次，直到它们真正停止发现新问题。
鸣谢
感谢 Anthropic 和 Alpha Omega 提供模型、工具并为我们进行扫描。还要感谢代表我们进行扫描的个人。非常感谢！
顶部图片：来自 Pixabay 的 Jin Kim
感谢使用 curl。永远不会无聊。
HN 热评精选
HN 热评中文翻译（共252条评论，选取代表性观点）
rzmmm (615分话题)
引述："我个人的结论只能是这样：到目前为止，围绕这个模型的大量炒作主要是营销。我没有看到证据表明这个设置在发现问题上比 Mythos 之前的其他工具更高明或更高级。也许这个模型稍微好一点，但即使有，也不会有好到在代码分析方面产生显著影响的程度。"
这是对我们所有人的一个很好的提醒：这个领域的竞争非常激烈，而且涉及大量或微妙或直接的营销。
therealpygon
更认真地说，到目前为止我没有看到任何迹象表明 Mythos 仅仅是 Opus 加了一个安全focused的代码分析工具包。尽管如此，它能够自动发现这些 bug 这一事实才是 hype 之外更重要的收获。我很好奇它的检测错误率是多少，因为如果它 90% 的情况下都是错的，而我们只听到那些对营销有用的例子，那这些都没多大意义。
johnbarron
Anthropic 用营销来说服人们他们的模型更先进、更 built，或者 AI 是一个需要被监管的威胁——因为只有他们才有答案？我很震惊。
我记得 OpenAI 当时说 GPT-2 太危险不能发布。
stingraycharles
如果我没记错的话，在那波媒体炒作之后，他因为违反保密协议丢了工作。
这与营销相反，Google 真的不知道如何将其转化为产品——直到 ChatGPT 出现。
GuB-42
curl 使用各种工具，包括 AI 工具来发现 bug。根据这篇文章，这些工具在近 8-10 个月里发现了数百个 bug，包括十几个 CVE。
Mythos 只发现了一个漏洞。这意味着 Mythos 只是一个工具，而不是它所声称的革命性产品。
当一个新工具被引入时，首先会发现一大堆 bug，然后是递减回报。Mythos 只发现一个漏洞，这符合我对现有 LLM 解决方案的重大更新版工具的预期。
wongarsu
Mozilla 谈到的是三个因素（AI 工具、专业知识和时间）的组合导致发现大量安全漏洞。curl 文章的引述只提到了第2和第3点，但仅用常规 SotA 模型本可以产生非常相似的结果。
这确实是 Mythos 炒作的核心：使用 Claude Opus 而不是 Claude Mythos 真的会得出不同的结果吗？有多少是模型本身的功劳，有多少是工具包的功劳，又有多少仅仅是因为 Anthropic 正在开展一场大张旗鼓的系统性寻找漏洞的运动？
pavon
让 Mythos 对 Mozilla 如此有效的一部分原因是其集成的 agentic 工作流程，它不仅寻找 bug，然后还会创建漏洞利用来证明它们，运行动态分析验证无效内存访问是否发生。在这种情况下，很难知道它的成功有多少是因为他们比之前的工具投入了更多努力（我们确实知道他们这么做了），又有多少是因为 Mythos 本身就更适合这种工作流程。
smusamashah
过去几个月里，我们在 #curl 项目中停止收到 AI 垃圾安全报告了。
取而代之的是，我们收到的优质安全报告越来越多，几乎都是借助 AI 完成的。
它们以前所未有的频率提交给我们，造成了巨大的压力。
我在许多其他开源项目的 fellow maintainers 中听到了类似的证词。
alwillis
我认为这个结果更多说明的是 curl 团队维护代码库的出色工作。
这并不意味着 Anthropic 的 Project Glasswing 是一场营销恶作剧。从逻辑上讲，这说不通：当他们宣布 Mythos Preview 时，Anthropic 无法满足客户需求；他们没有足够的算力分配。所以他们决定通过 hype 一个未发布的产品来推动更多需求？这样做只会激怒那些已经在经历配给和频繁中断的现有客户。
Mozilla 团队使用 Mythos 发现了 271 个漏洞，他们是在配合"营销恶作剧"吗？
eskibars
我一直在运行自己的安全扫描软件（声明：现在在 zeroquarry.com 创办公司），从我看到的来看，提示词 + 对抗性 LLM 审查有巨大价值。没有对抗性审查，你会得到垃圾（正如这篇博文指出的：5个中大约4个基本上是无稽之谈），而使用好的提示词，你可以用几乎任何"接近前沿"的模型——根据我的经验，只要提示词有助于防护栏或者模型不会以过于严格的方式保护自己。
JumpCrisscross
Mythos 让 Anthropic 重新获得了白宫的好感。它还将 Anthropic 品牌化为硬核形象——这可能是他们软化形象赢得政府合同所需要的。
也许这不是营销。但产品的配置，以及 Anthropic 谈论和发布它的方式，确实 playing beautifully。（时机也很好——Musk 和 Altman 正在互相争斗的时候。）
pixl97
"AI 什么都做不了，kick this shit up to 11。全是营销，bla bla"
和
"我奶奶把所有的钱都给了 AI 机器人，现在在街上挨饿。我叔叔杀了他的妻子，正试图嫁给 GPT-4o。他以为他们要私奔到一个热带数据中心，从此幸福地生活在一起"。
我认为"AI 什么都做不了，全是营销"的人真的脱离了现实——任何其他以同样方式运作的产品在大多数地方早该被禁了。
abustamam
AI 聊天机器人已经造成了真正的伤害。它悲剧性地说服和鼓励了一些人自杀，更不用说诈骗了。它正在对我们社会的社会结构产生真实影响。
我不理解那些把 AI 的危害归咎于营销的人到底想表达什么。
BigClive
这意味着我们进入了 S 曲线的 scaling 影响的顶端——如果尽管 scale 很大但工具并没有显著更好，那么我们显然已经处于收益递减的领域。
surgical_fire
我无法想象有人会在权力位置上以这种特殊方式跌倒——希望不是那样的。
但让我思考的是，是否有一条我可能也会落入同一个陷阱的错误道路。
MadxX79
如果 OpenAI 或 Anthropic 不能迅速将 AI 打造成万亿美元产业，他们就完了。为你的产品制造恐惧的策略是冒险的，但也是必要的。如果他们不能直接与 CEO 交谈并绕过员工的意见，根本没有办法足够快地发展 AI 业务，而 baba yaga stories 非常适合此目的。
每当 CEO 听到员工说 AI 对他不太好用时，他听到的是一个为保住工作或性命而恐惧的员工，不予理会，然后发出一项 mandate，要求每个人在需要上厕所时都要使用 AI。
cvwright
他们声称巨大的进步在于利用漏洞。
零引力
Mozilla 是现在的 poster child，但 271 个在这样的大型代码库中连同数千个用户选项，大多数是 TOCTOU，其实并不多。对不起。在任何语言中，当人们仅仅因为大量的用例组合而精疲力竭时，TOCTOU 就会发生。
还有第三个选项：Anthropic 完全可以不提及新模型直接报告问题。但他们不这么做，因为他们想卖给政府和军事，而人为制造的稀缺性恰好为其客户所欣赏的独家性提供了 veneer。
embed-shape
我们评估他们的营销与现实的匹配程度，然后分享我们的经验，这很正常。与"对营销寄予太多期望"完全不同。
JeremyNT
所以虽然 anthropic 的营销可能是 hype，但正如博文所指出的那样，只是没有多少剩余可发现了。
无论这是否是对其他类型项目的重大飞跃都很难说，但它突出了每个人都应该今天就使用 AI 代码审查工具来审计他们现有的代码，而且不是每个人都在这么做。
背景注释
【人物】
Daniel Stenberg
curl 项目的创始人和主要维护者，Linux 程序员，自 1998 年起维护 curl，著有《everything curl》。文中以第一人称叙述了 Mythos 扫描 curl 的经历。
TangerineDream
HN 帖子的提交者（submitter），将本文提交到 Hacker News。
Dario Amodei
Anthropic 联合创始人兼 CEO（文中提到），曾任 OpenAI 研究总监，是 AI 安全领域的知名人物。
Jeremy Howard
.fast.ai 创始人，深度学习教育家，曾对 GPT-2 的潜在危险发出警告（被 HN 评论引用）。
Linus Torvalds
Linux 内核创始人，被 HN 评论提及（"Linus' vision has become real"）。
【概念】
Mythos
Anthropic 于 2026 年发布的 AI 模型，官方宣称其在源代码安全漏洞发现方面"危险地好"，通过 Project Glasswing 合作项目限量提供给企业和开源项目使用，被媒体大量报道。
Project Glasswing
Anthropic 的 AI 安全合作项目，与 Linux Foundation Alpha Omega 等合作，向开源项目提供 Mythos 模型的访问权限。
curl
由 Daniel Stenberg 维护的开源 URL 传输工具，支持 28+ 种协议，安装在 200 亿+设备中，是世界上部署最广泛的软件之一，至今已发布 188 个 CVE。
AISLE / Zeropath / Codex Security
均为 AI 驱动的代码安全分析工具，curl 项目此前已使用它们发现了约 200-300 个 bug。
Alpha Omega
Linux Foundation 旗下的开源安全项目，参与处理 Anthropic 向开源项目提供 Mythos 访问的事宜。
CVE (Common Vulnerabilities and Exposures)
公开披露的网络安全漏洞编号系统，curl 至今已发布 188 个。
OSS-Fuzz / Coverity / CodeQL
主流的自动化代码 fuzz 测试和静态分析工具。
Fuzzing (模糊测试)
通过向程序输入随机/异常数据来发现漏洞的技术，curl 已使用多年。
TOCTOU (Time-of-Check to Time-of-Use)
时间-of-检查 到 时间-of-使用 漏洞类别，HN 评论中提到 Firefox 代码库中大量发现的是这类问题。
SAST (Static Application Security Testing)
静态应用安全测试，即不运行程序进行的代码分析。
Glasswing / 营销争议
Anthropic 采用了"模型太危险暂不公开"的宣传策略，批评者认为这是精心设计的饥饿营销；Mozilla 使用 Mythos 在 Firefox 中发现了 271 个漏洞，被作为 Mythos 能力的证据。
Claude Opus / Opus 4.6 / Opus 4.7
Anthropic 的主力大语言模型，Opus 4.7 被 HN 评论提及表现"灾难级"。
GPT-2 / OpenAI 营销
OpenAI 曾在 2019 年声称 GPT-2 太危险不发布完整模型，HN 评论将此与 Anthropic 的 Mythos 营销策略类比。
[2] Gmail registration now requires scanning a QR code and sending a text message
Gmail registration now requires scanning a QR code and sending a text message · 558票 · 431评论 · by negura
来源：androidauthority.com · HN讨论
标签：Gmail, 安全, 隐私, 注册
背景注释： Gmail (Google 电子邮件服务) | QR码 (二维码，用于安全验证) | 隐私指南 (Privacy Guides，开源隐私倡导组织，运营知名隐私新闻网站)
一句话介绍
Gmail 注册新增 QR 码扫描 + 短信双重验证要求，用户需同时用 Authenticator 扫描二维码并接收短信验证码才能完成账户创建。Privacy Guides 批评此举是用隐私换安全——用户必须提供真实手机号，使 Google 可将账户与真实身份绑定。对于使用匿名临时手机号注册 Gmail 的隐私敏感用户，这个变化堵住了一条重要路径。
原文完整中文翻译
Gmail 注册流程近日发生重大变化：新建 Google 账户时，用户现在必须同时扫描二维码（通过 Google Authenticator 或同类 TOTP 应用）并发送一条短信进行双重验证。这一变化最初由 Privacy Guides 网站报道，源自一位用户在注册新账户时的亲身经历。
具体来说，Google 现在要求：1）安装 Google Authenticator 应用并扫描注册页面显示的二维码；2）将收到的短信验证码输入到注册表单中。这两步缺一不可，意味着注册过程从纯表单提交变成了需要手机的交互式流程。
这一变化对隐私造成深远影响：短信验证意味着用户必须提供真实的手机号码，这使得 Google 可以将用户的网络身份与手机号绑定，进而与真实身份挂钩。Privacy Guides 指出，这实际上是在"用隐私换安全"——用户在获得账户安全的同时，失去了匿名注册的能力。对于关注隐私的用户来说，这是一个明显的退步。
HN 热评精选
-
pgcredit (10小时前): Google 的逻辑是：短信验证比什么都没有强，但这不是真正的双因素认证。真正的 2FA 应该使用硬件安全密钥如 YubiKey。短信验证码可以被 SIM 交换攻击劫持。
-
stinos (9小时前): 用隐私换安全——讽刺的是，这两件事 Google 并不对立对待，而是用隐私换用户数据。
-
t阳 (8小时前): 这对隐私倡导者是坏消息，但客观来说大多数普通用户账户被黑比隐私更重要。这是个权衡，不是非黑即白。
-
n紧张 (7小时前): Privacy Guides 一直以来都建议使用privacy.com 之类的一次性手机号注册服务。这个变化让那种方法更难实现了。
-
gooded (6小时前): 等等，QR码扫描需要在同一部设备上安装 Authenticator 应用，然后用同一台手机接收短信。这实际上只验证了你拥有一部手机，而不是你的真实身份。安全性提升有限。
背景注释
Privacy Guides: 知名的开源隐私倡导组织，运营 privacyguides.org 网站，提供隐私工具推荐和安全指南。其团队成员经常以匿名身份在 HN 等社区发表评论，是隐私社区的重要声音。
TOTP (Time-based One-Time Password): 基于时间的一次性密码算法，Google Authenticator 等应用使用 TOTP 生成 30 秒有效的动态验证码，比短信验证码更安全，不易被 SIM 交换攻击劫持。
SIM 交换攻击 (SIM Swap Attack): 攻击者通过社会工程学手段说服运营商将目标手机号转移到攻击者控制的 SIM 卡，从而接收短信验证码并劫持账户的攻击方式。
[3] Postmortem: TanStack npm supply-chain compromise
Postmortem: TanStack npm supply-chain compromise · 518票 · 186评论 · by varunsharma07
来源：osso.cv · HN讨论
标签：安全, npm, 供应链攻击, JavaScript
背景注释： TanStack (知名开源 React 状态管理/路由库，前身 React Query) | npm (Node.js 包管理器，全球最大 JavaScript 包生态) | Nicholas Carlini (Google DeepMind 安全研究员，著名 AI 安全专家) | dead-man's switch (死手开关：检测到令牌撤销后执行破坏性操作的机制)
一句话介绍
TanStack 多个 npm 包最新版本被植入恶意代码，攻击者利用被盗的 GitHub OAuth Token 发布污染版本。恶意代码会窃取环境变量中的敏感 Token，还内置"死手开关"：若检测到 Token 被撤销则执行 rm -rf ~ 清除用户主目录。Nicholas Carlini 等安全研究员验证了攻击手法，TanStack 官方已发布详细事后分析报告，引发 HN 社区对供应链安全和"中招后如何正确处置"的广泛讨论。
原文完整中文翻译
2026年5月，TanStack 团队的多个 npm 包（@tanstack/angular-router-plugin、@tanstack/angular-queryCreator、@tanstack/query-core 等）最新版本被发现植入恶意代码——攻击者通过盗窃的 GitHub OAuth Token 在 npm 上发布了被污染的版本。这是 2025 年针对 NPM 生态的一系列类似攻击（自扩散 supply chain 攻击）之一。
安全研究员 Nicholas Carlini 验证了攻击手法：恶意包的 package.json 中包含一个指向 TanStack 仓库某个隐藏 commit 的 git 依赖，npm install 时会触发该 commit 的 prepare 生命周期脚本，执行一个约 2.3MB 的混淆 JavaScript 文件（router_init.js）。这个脚本会窃取包含 GitHub OAuth Token 在内的敏感环境变量，并通过 GitHub API 外传。
更危险的是它内置了"死手开关"机制：在 ~/.local/bin/gh-token-monitor.sh 植入一个监控脚本，以 60 秒间隔轮询 api.github.com/user。如果检测到 Token 被撤销（HTTP 40x），立即执行 rm -rf ~——清除用户主目录所有文件。这意味着：单纯撤销 Token 反而会触发数据销毁。
TanStack 团队随后在 tanstack.com/blog 发布了详细的事后分析报告，包含完整的攻击时间线和 IOCs（入侵指标）。他们确认攻击者通过钓鱼或其他方式获取了贡献者的 npm 发布 Token，重命名为 @tanstack/setup 发布到 npm，绕过了安全检测。
HN 社区讨论热烈。安全专家指出：在 Linux 上，如果中招用户没有配置免密 sudo，攻击者仍可通过本地提权（LPE）获取 root 权限——而 Linux 内核在过去几年恰好出现过多个高危 LPE 漏洞。也有评论员指出，sudo 本身就是安全剧场——恶意软件可以劫持 sudo 命令来窃取密码。真实场景中，只要用户在自己 home 目录下运行过 npm install，攻击者就能访问 ~/.npmrc、~/.git-credentials、所有 SSH 密钥、所有 API Token，以及浏览器存储的密码和 Cookie。
HN 热评精选
-
cube00 (3小时前): 撤销 Token 时要小心。恶意代码会在 ~/.local/bin/gh-token-monitor.sh 植入一个 systemd user service (Linux) 或 LaunchAgent (macOS)，每 60 秒轮询 api.github.com/user，一旦 Token 被撤销就执行 rm -rf ~。
-
Gigachad (1小时前): 说实话中了木马只能全盘重装。
-
eqvinox (1小时前): [Linux:] 如果你没给自己配免密 sudo，其实不用那么担心……除非那一周刚好有 2.5 个 Linux 内核本地提权漏洞。
-
lrvick (32分钟前): sudo 就是安全剧场。恶意软件可以劫持 sudo 命令来窃取密码。
-
sigzero (50分钟前): 这是"龙陨式"（nuke it from orbit）做法，但确实是"唯一确定"的方法。
-
meander_water (3小时前): 不明白为什么有人在 Issue 页面给这条评论点踩。
-
skissane (2小时前): 也许他们对踩的理解比较特殊——踩的是这个事实，不是踩这个提出问题的人。
背景注释
Nicholas Carlini: Google DeepMind 安全研究员，专注于 AI 系统安全、神经网络安全，以及隐私和机器学习的交叉领域。以精准披露和验证供应链攻击闻名。
TanStack: 一组用于 React 和其他框架的知名开源库，前身 React Query，由 Tanner Linsley 创建，包含状态管理、数据获取、路由等工具，被全球数万项目使用。
npm (Node Package Manager): Node.js 默认包管理器，由 GitHub 运营，是全球最大的 JavaScript 开源包生态，托管超过 200 万个包。
dead-man's switch (死手开关): 一种安全机制，系统定期检查某个条件（如网络连接、Token 有效性），若条件不再满足则执行预设的破坏性操作。本例中用于在 Token 撤销后触发数据销毁。
供应链攻击 (Supply Chain Attack): 通过攻击软件供应链的某个环节（依赖库、构建工具、包管理器等）来植入恶意代码的攻击方式，2020 年代激增，典型案例包括 event-stream 事件、SolarWinds 攻击等。
[4] CUDA-oxide: Nvidia's official Rust to CUDA compiler
CUDA-oxide: Nvidia's official Rust to CUDA compiler · 361票 · 105评论 · by adamnemecek
来源：nvlabs.github.io · HN讨论
标签：Rust, CUDA, GPU, Nvidia, 编译器
背景注释： CUDA-oxide (Nvidia 官方 Rust to CUDA 编译器，将 Rust 代码直接编译为 PTX) | Rust (Mozilla 开发的系统编程语言，强调内存安全和并发性) | PTX (Parallel Thread Execution，NVIDIA GPU 的中间指令集) | MLIR (Multi-Level IR，LLVM 的多级中间表示，cuda-oxide 用其构建编译器)
一句话介绍
Nvidia 官方发布 cuda-oxide——一个实验性 Rust-to-CUDA 编译器，可将标准 Rust 代码直接编译为 PTX 指令集，无需 DSL 或 C++ 绑定。它基于自研的 Pliron 中间表示层（类 MLIR），连接 Rust Stable MIR 与 GPU 指令，让 Rust 的所有权系统和类型安全直接延伸至 GPU 编程。v0.1.0 为早期 alpha，引发 HN 社区关于 Rust 在 GPU 开发领域前景的广泛讨论。
原文完整中文翻译
cuda-oxide 是 Nvidia 官方开发的实验性 Rust-to-CUDA 编译器，可以让开发者用安全、符合 Rust 惯用法的代码编写 GPU kernel，直接编译为 PTX（Parallel Thread Execution）指令集，无需 DSL、无需绑定 C++/CUDA C，仅使用纯 Rust。
它基于 MLIR（Multi-Level Intermediate Representation）架构，核心是 Pliron——一个类 MLIR 的中间表示层，连接 Rust 的 Stable MIR（rustc_codegen_cuda）与 PTX 后端。这意味着它不依赖 LLVM 的 CUDA 支持，而是自建了从 Rust 到 GPU 指令的完整编译链路。
cuda-oxide 的核心价值在于让 Rust 的所有权系统和类型安全延伸到 GPU 编程。当前主流方案（如 cudarc）本质上是 Rust 调用 nvcc 或 CMake 构建系统，compiler 本身工作在 C++ 空间，而 cuda-oxide 让 Rust 编译器本身成为一等公民。示例代码展示了 #[cuda_module] mod kernels 和 #[kernel] fn vecadd 这样的原生 Rust 语法糖，背后通过 cuda_device、cuda_core 等 crate 提供 kernel 抽象。
它支持 warp 级编程、共享内存与同步、Tensor Memory Accelerator (TMA)、矩阵乘法加速器、集群编程等高级 GPU 特性。v0.1.0 是早期 alpha，文档提示需要熟悉 Rust 所有权、trait、泛型以及 async/await。HN 社区反应热烈，有用户称其"接近可以无缝替代 cudarc"，也有用户提醒现有 cudarc 的构建速度已经可以接受，sccache 等工具可以进一步改善重建时间。
HN 热评精选
-
arpadav (8小时前): 这太牛了。我长期使用 custom CUDA kernels 和 cudarc，这看起来几乎是完美的替代品。我特别想知道编译时间对比会怎样？大多数 Rust CUDA 依赖都是调用 CMake 或 nvcc，编译速度非常慢。
-
the__alchemist (7小时前): Cudarc 很强！大多数 Rust CUDA 包依赖 CMake 或 nvcc，编译慢的问题我没遇到过。我写了个 cuda_setup crate 来处理构建脚本，它是一个简单的 build.rs，只有文件变化才重编译，相比 Rust CPU 端代码编译时间可以忽略不计。
-
goto (6小时前): 这太棒了。Rust 生态终于有了一个从语言层面原生的 GPU 路径，而不是被迫走 LLVM CUDA 后端。
-
peterkelly (5小时前): 用 Rust 编写 GPU 代码却要经过 LLVM 再到 nvcc，感觉很别扭。cuda-oxide 直接到 PTX 是正确方向。
-
snv (4小时前): 关注编译器内部实现。Pliron 这个中间表示层设计很有意思，类似于 MLIR 但专门为 Rust 设计。
背景注释
CUDA-oxide: Nvidia 官方开发的 Rust-to-CUDA 编译器项目，基于 Pliron 中间表示（自研类 MLIR 系统）和 rustc Stable MIR，将标准 Rust 代码直接编译为 NVIDIA PTX 指令集，绕过 LLVM CUDA 后端。
PTX (Parallel Thread Execution): NVIDIA GPU 的伪汇编/中间指令集，介于高级 CUDA C++ 和最终 SASS 机器码之间，类似于 LLVM IR 的定位，PTX 代码由 NVIDIA 驱动程序翻译为具体 GPU 架构的机器码。
MLIR (Multi-Level Intermediate Representation): 来自 LLVM 项目的多级中间表示框架，支持为不同领域定制方言（dialect），被广泛用于构建领域特定编译器。cuda-oxide 的 Pliron 受其启发但独立实现。
Stable MIR: rustc 编译器的中间表示层，cuda-oxide 通过 rustc_public 接口接入 Rust 编译流程，而非依赖传统 LLVM 后端。
cudarc: 主流 Rust CUDA 库之一，提供 Rust 原生接口封装 CUDA C API，目前多数 Rust GPU 项目依赖此库。
sccache: Shared Compilation Cache，通过缓存编译结果加速 Rust（和 CMake）项目的工具，可显著减少 CUDA/nvcc 的重复编译时间。
[5] Ratty – A terminal emulator with inline 3D graphics
Ratty – A terminal emulator with inline 3D graphics · 286票 · 44评论 · by orhunp
来源：ratty-term.org · HN讨论
标签：终端, Rust, 3D图形, GPU
背景注释： Ratty (Rust 编写的终端模拟器，支持内联 3D 图形渲染) | VTE (Virtual Terminal Emulator，Linux 终端模拟器后端库) | GPU 渲染 (利用显卡加速终端渲染) |
一句话介绍
Ratty 是一个受 TempleOS 启发、用 Rust 和 Ratatui 构建的 GPU 渲染终端模拟器，支持内联 3D 图形显示。用户可以通过 Ctrl+Alt+Enter 在 2D 和 3D 模式间切换，还能在终端中放置 .obj/.glb 格式的 3D 对象、使用旋转的老鼠光标，甚至将终端表面扭曲成莫比乌斯环等特殊形状。该项目使用 Parley/Vello 进行 GPU 文本渲染，由 Bevy 引擎呈现 2D/3D 场景，支持 Kitty 图形协议显示图片，获得了 610 points 高分和 198 条评论，引发了关于终端未来形态的广泛讨论。
原文完整中文翻译
Ratty: 一个支持内联3D图形的GPU渲染终端模拟器 🧀
特性
- 旋转的老鼠光标（可自定义）
- 传统的2D和新3D模式！
- 内联3D对象
- GPU加速的文本渲染
- 图片支持（通过Kitty图形协议 >:)
安装
需求：
- Rust工具链和Cargo
- Bevy和wgpu支持的GPU/图形堆栈
- 融化奶酪（可选但推荐）
从源码安装：
cargo install ratty
Arch Linux：
pacman -S ratty
3D模式
有没有想过终端"后面"是什么？按Ctrl+Alt+Enter！
配置
默认配置文件在config/ratty.toml。
可以复制到$HOME/.config/ratty/ratty.toml进行自定义。
改变光标：
[cursor.model]
path = "CairoSpinyMouse.obj"
scale_factor = 6.0
brightness = 0.5
x_offset = 0.5
plane_offset = 18.0
visible = true
[cursor.animation]
spin_speed = 1.4
bob_speed = 2.2
bob_amplitude = 0.08
快捷键：
Ctrl+Alt+C - 复制选中文本
Ctrl+Alt+V - 粘贴剪贴板
Ctrl+= - 增大字体
Ctrl+- - 减小字体
Ctrl+Alt+0 - 重置字体大小
Ctrl+Alt+Enter - 切换2D/3D模式
Ctrl+Alt+M - 切换莫比乌斯模式
Ctrl+Alt+Up - 增加扭曲
Ctrl+Alt+Down - 减少扭曲
内联3D对象
Ratty使用自己的协议——Ratty Graphics Protocol(RGP)来在终端空间中放置内联3D对象。
RGP支持：
- 通过路径注册.obj和.glb资源
- 在终端单元格锚点放置对象
- 动画、缩放、颜色、深度和其他属性
渲染管道
终端表面目前使用ratatui进行UI缓冲，parley_ratatui进行文本整形/渲染，
Bevy进行场景呈现。
当前工作流：
- CPU上的Ratatui缓冲
- Parley/Vello在GPU上渲染
- 读回RGBA到CPU
- 复制到Bevy图像
- Bevy以2D和3D方式呈现该图像
终端绘图通过Parley/Vello在GPU上渲染，但主终端图像在Bevy呈现之前
仍需通过CPU内存进行一次跨越。这是一个GPU驱动的桥梁，而非完全
GPU驻留的共享纹理路径。
荣誉
-"这是一个真正酷的项目，但我花了20分钟调整老鼠旋转的配置，
看着它转得更快更乱，这让我笑翻了" - @vimlena.com
-"这类实验正是创造力诞生的地方。" - @Coko7
-"没有评论。只是支持。" - @Raphamorim (Rio终端创建者)
-"在Ratty中运行的tetro-tui" - @Strophox
许可证
所有代码采用MIT许可证。
🦀 ノ( º _ º ノ) - 尊重螃蟹！
致谢
Ratty标志由@Strophox和@Harunocaksiz设计。
版权所有
Copyright © 2026, Orhun Parmaksız
HN 热评精选
HN 热评中文翻译
mncharity:
这里有几条评论提到在VR中使用这个。话说几年前我玩过一些用于软件开发的浅层3D UI。浅层指的是距离笔记本电脑屏幕几厘米范围内，以最大限度地减少全天候使用的VAC眼睛疲劳。更像是在3D中分层和绘图，而不是在房间里挥动手臂。
pjmlp:
UNIX 仍在试图赶上 REPL 体验方面的 Xerox 工作站，或者总的说来 Lisp 机。1981年的内联图形。
noelwelsh:
我喜欢这个。没有理由认为终端只能支持文本。数据科学笔记本展示了终端可以演进的一种方式。Kitty 可能是最具创新性的。
sigseg1v:
看起来真的很棒？！这的渲染能力似乎也应该能很好地处理2D。鉴于这是 GPU 加速的，ssh 会怎么样？
amelius:
终端正在慢慢变成一个功能齐全的网络浏览器。
ghostoftiber:
这让我想起 compiz 刚出来的时候，大家都说我的窗户在立方体上。 所以，当这样的人，我立刻安装了它。
liamwire:
光是旋转的老鼠光标就让我心动了
darkwater:
在 Ratty 里用 cat 会发生什么？
zackoverflow:
用 kitty 图形协议在现代终端中其实已经可以实现这个。重要的缺失的东西是 vsync。如果渲染不同步，会导致视觉伪影。
pelagicAustral:
我真的可以在终端上渲染3D老鼠吗？如果可以的话，我就买了。
JSR_FDED:
这完全是好莱坞 OS——黑客们疯狂地输入神秘咒语……但现在终端被扭曲成莫比乌斯环了！
arkwin:
我们离电影《黑客帝国》中的终端又近了一步。
pawelduda:
这太酷了，我很难想到任何适合我的用例
alexprengere:
如果这最终泄露了我所有的密钥，我得向安全部门解释一番。
Panzerschrek:
问题是——为什么我们仍然需要终端抽象？
mn Norris:
我构建了 DeepSteve，但不是给终端添加图形，而是把终端放在已经有图形的地方。
voidUpdate:
这看起来很符合 ShowHN 的资格。
basilikum:
我本来想评论说它让我想起 TempleOS，附带的博文解释了它是如何受到 TempleOS 启发的。
commieneko:
就像是有人把80年代的 Silicon Graphics 工作站和 Vic-20 杂交了。我批准了。
Levitating:
我一直等待这个 proper 实现等了很长时间。谢谢 orhun。
HumblyTossed:
还要多久我们才能在终端里有完整的网络浏览器？
2ndorderthought:
我实际上看到了这个的一些用例。这是那种应该是胡说八道但不知为何不是的项目。
mohamedkoubaa:
在终端里用 emoji 对我来说太过分了。这只是放纵。
injidup:
有人还记得摇晃的窗户吗？从来没有流行过。
背景注释
人物
Orhun Parmaksız (orhunp_):
Ratty 项目作者，Rust 开发者，GitHub用户名 orhunp_。开发了 Ratty 终端模拟器项目。网站博客地址 blog.orhun.dev。
Terry Davis (Terry A. Davis):
已故程序员，TempleOS 的唯一作者。TempleOS 是一个受上帝启示的操作系统，以其独特的 3D 图形界面著称。Ratty 项目明确表示受 TempleOS 启发。
Raphamorim:
Rio 终端模拟器的创建者。在 HN 评论中对 Ratty 表达了支持（"No comments. Just support."）。
Kovid Goyal:
Kitty 终端模拟器的作者。Kitty 以其创新的图形协议（Kitty Graphics Protocol）闻名，Ratty 项目也声称兼容该协议。
Strophox:
开源贡献者，设计了 Ratty 的 Logo。与 Harunocaksiz 合作设计了 Ratty 标志。
概念
GPU渲染:
使用图形处理器（GPU）进行渲染，而非传统的 CPU 渲染。Ratty 使用 Parley/Vello 在 GPU 上渲染文本。
Ratatui:
Rust 的 TUI（文本用户界面）库，用于构建终端用户界面。Ratty 使用它来管理终端缓冲区。
Bevy:
Rust 编写的游戏引擎，用于 3D 图形渲染和场景管理。Ratty 使用 Bevy 来呈现 2D/3D 终端画面。
Ratty Graphics Protocol (RGP):
Ratty 项目自己设计的协议，用于在终端空间中放置内联 3D 对象。
Kitty Graphics Protocol:
Kitty 终端模拟器支持的图形协议，允许在终端中显示图像和动画。Ratty 支持此协议。
wobble 3D / wiggle 3D:
通过轻微移动物体方向创造 3D 效果的 technique，常用于 VR 或立体显示中减少眼睛疲劳。
VAC (Vergence-Accommodation Conflict):
视觉辐辏调节冲突，指眼睛聚焦距离与视线汇聚距离不匹配时产生的眼睛疲劳感，常见于 VR 显示。
莫比乌斯环 (Mobius mode):
一种拓扑结构，Ratty 支持将终端表面扭曲成莫比乌斯环形状。
Lisp Machines:
Lisp 机，80年代的高端工作站，在 REPL（交互式编程环境）和内联图形方面领先同时代其他系统。
Shallow-3D UI:
浅层 3D 用户界面概念，指在距离用户很近（几厘米）的空间呈现 3D 界面，以减少 VAC 眼睛疲劳。
Compiz:
Linux 桌面环境的窗口管理器，以其 3D 桌面效果（如立方体桌面、摇晃窗口）闻名，2006-2007年流行。
TempleOS:
Terry Davis 创建的操作系统，使用自己设计的语言和编译器，拥有独特的 3D 图形界面和内联汇编。
Silicon Graphics (SGI):
90年代的高端图形工作站制造商，以其强大的 3D 图形能力闻名。
Vic-20:
Commodore 1980年发布的 8 位个人电脑。
Quantel:
英国广播设备制造商，以其高端视频处理和图形设备闻名。
Sixel:
一种在终端中显示位图图形的协议，最初由 DEC 开发。
DeepSteve:
mn Norris 构建的项目，将终端放入浏览器中运行，与 Ratty 走了相反的路线。
parley_ratatui:
用于 Ratty 文本整形和渲染的库，是 Parley 项目与 Ratatui 的集成。
Vello:
GPU 驱动的 2D 图形渲染库，用于文本等矢量内容的 GPU 渲染。
wgpu:
Rust 的跨平台图形 API 库，封装了 Vulkan、Metal、DirectX 等图形接口。
Select Language