0818 | Wiz Red Agent攻破Snowflake GitHub漏洞；亚马逊切书脊购书喂AI；OpenRouter折扣GPT-5.6 Sol；GitHub事故

林岚: 欢迎收听 Bri 电台的《HackerNews每日沙龙》，我是林岚。

陈序: 我是陈序。今天这期内容挺有看头——一次直接摸进企业内部系统的安全研究，以及跟 AI 训练有关的不少新消息。

林岚: 先说安全这条线。有研究团队借助一个公开漏洞悬赏平台，在云服务商 Snowflake 的系统里发现并利用了一个工作流漏洞，最后拿到了它内部系统里的敏感数据。

陈序: 另外几件事也值得留意：苹果在德国的监管压力下要调整广告数据的使用规则；还有一个开源数据库项目发布了新的大版本预览。当然，也少不了围绕 AI 模型和 AI 用书的讨论。

林岚: 安全研究公司 Wiz 的自主 AI 工具 Red Agent，在 Snowflake 的公开漏洞悬赏平台上发现并攻破了一个 GitHub Actions 工作流的致命漏洞，最终拿到了 Snowflake 内部项目管理工具 Jira 里的敏感数据。这个漏洞藏在一个公开代码仓库里，属于脚本注入，任何 GitHub 用户只要打开一个标题经过特殊构造的 issue，就能在运行 GitHub 自动化的服务器上执行任意命令。

陈序: 这个漏洞是今年六月一个名为“更新 Jira 工作流”的提交引入的，而且这个提交是由 GitHub 的 AI 自动修复功能共同编写的。之前代码是用安全的方式把 issue 标题作为环境变量传递，AI 助手却把它反过来，直接把标题文本插进 shell 脚本里，从而给攻击者打开了任意命令执行的口子。

林岚: 更讽刺的是，这个工作流看起来有访问保护条件，但对于普通的 issue 事件来说，那个条件里的判断值永远是空的，所以这个保护对每个 GitHub 用户都形同虚设。Red Agent 第一次尝试外泄时还因为注释字符触发了一个语法错误，它自己分析错误、修复了写法，第二次成功把包含登录凭据的回调传了回来。

陈序: 这些凭据确实能登录 Snowflake 的 Atlassian 系统，并且对工程、安全合规和漏洞悬赏这几个项目都有读取权限。Red Agent 在当天完成了攻击，Snowflake 也在同一天完成修补，恢复了原先安全的解析方式，轮换了受影响的凭据，并通过审计日志确认 Wiz 是漏洞暴露窗口内唯一的行动者。Wiz 也确认在测试中访问的所有数据都已经安全删除。

林岚: 这个案例在技术圈子里引发了很多关于 AI 代码审查的讨论。有人强调对代码变更的同行评审依然重要，但也有人反驳说，不能指望人眼看出这种变更里的隐患，还有人指出这个提交里其实没有任何明显的红旗。另一派观点主张引入自动化注入检查这样的测试工具来兜底。

陈序: 还有评论者提到，有人想自动审查并自动批准那些标注为“微小改动”的 AI 提交，但反驳者说得很直接：如果模型的能力不足以防止出问题，那它也不足以判断什么是微小改动。有人建议用多个模型交叉审查，但也有人泼冷水说那只是往流水线里塞进更多东西，人还得亲自把关。这个话题的评论区最后留下的普遍感慨是——引号注入这种老问题，到了 2026 年居然还能出现。

林岚: 科技媒体 TechCrunch 和调查媒体 404 Media 最近报出了一件引发热议的事：亚马逊正在大量购买稀有书籍，切掉书脊、扫描内容，用来训练人工智能模型。404 Media 在一本珍本里藏了追踪装置，结果显示那本书最终被送进了拉斯维加斯一座亚马逊仓储设施，而这座设施的标识正好就是一只拿着书的恐龙。

陈序: 亚马逊对此回应说，它是通过商业渠道购买书籍的，目的是改善客户使用的产品和服务。调查报道本身给出了一个合理的解释：稀有书，尤其是绝版或者网上找不到的文本，对训练大语言模型特别有价值，因为 2022 年之前出版的内容基本不可能由 AI 自己写出来——而如果模型摄入过多 AI 生成的东西，就可能出现所谓的“模型崩溃”质量问题。

林岚: 这个话题在技术社区引发了激烈争论。关于版权，有人问这种做法是否正好踩了版权法的红线；有人反驳说，就算你把原件毁掉，扫描出来的副本依然是副本。还有人提出，如果目的是训练而不把扫描件上传，也许存在灰色地带——但立即有评论者指出，销毁原件和扫描行为的版权问题其实毫无关系。

陈序: 也有人为亚马逊辩护，说买下的书自然可以随意处置，书又不是人，而且旁人本来也不太可能获得这些稀缺书。另一边则有人批评说，这篇报道本身并没有直接证明“毁书”，只是链接了 404 Media 的付费文章；但反驳者认为，亚马逊也不太可能专门去仔细剔除稀有书籍，还举了伦敦老书店剪下书页单卖的例子，说明独立书业自己未必在努力保存书籍。

林岚: 评论区对 TechCrunch 这篇标题的态度也比较复杂。有人觉得标题在强行制造联系，认为亚马逊卖书和毁书并行都是逐利行为，它知道这是可以利用的法律漏洞，好处大过了批评声。也有人干脆说“稀有”这词只是点击诱饵，还有人批评这份媒体已沦为带偏见的 AI 内容。但讨论里最尖锐的一点，是一位评论者所说的——整件事最糟的是其中的虚伪，并把它形容为在建造某种“折磨枢纽”过程中的一环。

林岚: 模型路由平台 OpenRouter 上，OpenAI 的旗舰大模型 GPT-5.6 Sol 正在促销，价格直接打了五折——输入每百万 token 两美元五十分，输出每百万 token 十五美元。这个模型号称擅长复杂推理、编码和智能体工作流，尤其在命令行和多步编程任务上表现出色，上下文窗口达到一百万 token，最大输出大约十二万八千 token，今年七月才发布。

陈序: 有意思的是，五折价格目前只适用于 OpenAI 自家的提供商渠道，而其他托管这个模型的几个云平台仍然维持原价。更重要的是，有人在评论区提醒说，这个降价仅限于 OpenRouter，并不适用于 OpenAI 官方定价页面上列出的价格，所以标题里的“降价 50%”其实有误导性。

林岚: 关于这个价格策略，有评论者认为，OpenAI 旗下更早的模型 Luna 在降价后已经出现大幅增长，现在推出 Sol 的五折促销，OpenAI 大概是想看看这个旗舰能抢占多少市场份额。但问题在于，市场上已经有一些更便宜、智能水平大体接近的对手，最突出的是 Grok 4.6，这让 Sol 变得不太好卖——针对这一点，也有人明确表示不相信那个竞品真有同样的智能水平。

陈序: 有个评论者甚至怀疑，xAI 是不是在把一些困难的查询悄悄 A/B 测试路由到 Sol，就为了暗中培养一批忠实用户。不过，这一测算术在讨论里并没有跑通，因为马上有人表了个态度：无论那个模型多有能力、多便宜，他都拒绝在经济上支持一位被认定与白人至上主义有牵连的公司的所有者。

林岚: 除了价格，大家也在聊模型的实际体验。有人发现 5.6 在简单任务上反而表现更差、容易把问题复杂化——他请它写一个用户待办清单，结果拿到一篇四页的文章，而用旧版本得到的只是一个清爽的小复选框列表。另一个评论者回应说，设置合适的思考级别本来就是用户的责任，简单任务应该选更轻量的模型，也可以直接要求它简洁回答。

陈序: 还有一个更现实的选择因素被拿了出来：很多企业用户只会在大模型血统最干净的几家之间做选择，因为只有这些厂商签有零数据保留协议，他们不信任随机的推理提供商，尤其不会拿敏感数据去碰。最后还有人提出了一个商业层面的疑问——这次降价，会不会其实是被流量中收集到的模型思维痕迹所带来的价值驱动的。

林岚: Roboflow 的博客作者 Piotr Skalski 发文说，OpenAI 上周发布的 GPT-5.6 系列（Sol、Terra 和 Luna）里，Sol 是 OpenAI 迄今最强的视觉模型，Terra 和 Luna 也有明显进步。他用自己计划几周内发布的基准测了目标检测，GPT-5.5 只拿 13.8 mAP@50，Sol 达到 46.2，文档布局检测是明显强项；不过作者提醒，GPT-5.6 用绝对 XYXY 像素坐标提示效果最好，用错坐标格式会掉约 15 个 mAP 点，而且 Sol 在约 2000×2000 像素及更大的图像上稳定性会下降。

陈序: 具体数字有多强？

林岚: 检测方面特别直观，上一代 GPT-5.5 只得了 13.8 分，Sol 一下子冲到 46 分多，Terra 和 Luna 也在 43 到 45 分之间。文档布局检测是这代的明显强项，像药片、鸡蛋这类重叠密集的场景也表现不错。不过作者特别提醒了一个很实用的坑：Sol 对绝对像素坐标的提示效果最好，而 Gemini 3.5 Flash 才用那种归一化坐标，格式用错了能让 GPT-5.6 直接掉十几分。

陈序: 那真就是格式决定成败了。它还会出什么别的错吗？

林岚: 会让它处理超大图的时候稳定性下降，OpenAI 自己都确认了，大约两千万像素及以上就不太稳。提高所谓推理强度能改善，但代价是更慢更贵，作者说最实用的办法还是先把图缩小或裁开。计数方面 Sol 到 73%，Terra 和 Luna 也都超过了旧版基线，连最便宜的 Luna 都能胜任。不过在数泡罩包装里的空槽和密封药片这种活上，还是会有具体困难。

陈序: 评论区里也有人拿它跟 Claude 比，有人做实验让两个模型去检查界面设计，Sol 能把页面重新拆成可组合的单元，而 Claude 太盯着局部、忽略了整体。不过也有人反对用大模型来评估这种主观质量，说这是最糟糕的用法之一；另一方则说主观质量背后其实有大量客观原则，问大模型反而是发现这些原则的好方法。还有人开玩笑说视觉模型哪来的品味，作者也自己在评论区补了一句：GPT-5.6 虽然比前代强很多，但还是远远比不上上周发布的 Gemini 3.5 或 3.7 Flash。

林岚: Artificial Analysis 测出，阿里巴巴开源模型 Qwen3.8 27B 在它的智能指数上拿了 52 分，而同类模型中位数只有 9 分。这个去年八月发布、走 Apache 2.0 开源许可的模型，支持图片和文本输入，上下文窗口 25 万六千个 token，约合 384 页 A4。评论里有人指出，这让它和远大于它的 GLM 5.2、GPT 5.6 Luna 等模型相当；不过评测发现它生成 1.6 亿 token，远高于 4300 万的中位数，属于非常啰嗦，每个任务产生的 token 几乎是前代的两倍。

陈序: 等一下，52 对 9 分，这差距是不是有点太大了？

林岚: 对，正因为如此，评论区很多人在看它到底处在什么位置。有人指出，这个成绩让它和体量大得多的 GLM 5.2 以及 GPT 5.6 Luna 这类模型画上了等号，也跟最新版 DeepSeek Flash 同分，而且在所有 Qwen 模型里排第二，只明显低于 Qwen 3.8 Max。不过也有人反问，说外界其实根本不知道 GLM 5.2 和 Luna 的实际规模，这种比较到底有多大参考价值，本身就是个值得怀疑的问题。

陈序: 那它这个高分是拿什么换来的？

林岚: 评论里有人观察到它在某项评估上反而比旧版 3.6 略有退步，怀疑是把一部分世界知识换成了别的能力；而且它每个任务输出的 token 几乎是 3.6 的两倍，非常啰嗦——跑完整个评估它生成了 1.6 亿个 token，同类中位数才 4300 万。也有人指出它比 Luna 更耗 token，约 2.3 倍，不利于本地部署。页面标的价格倒是很诱人，输入输出都是零美元，中位数分别是四分和一毛五。有分享亲身经验的人说，之前那个 27B 在笔记本上跑得动但每秒才 5 个 token 太慢，更大的版本倒是快，却完不成任务；他宁愿要慢两到三倍但能力更强的，本地跑代码这类技术活，小规模专用模型反而是合理方向。

林岚: librarian.net 发了一篇《如何禁用或避开侵入式AI》的指南，作者说这是他在图书馆被问得最多的问题之一，面向的是不想在自己不想看的地方被 AI 打扰的人。指南覆盖了 Adobe Acrobat、安卓的 Gemini、苹果智能助手、Chrome 和 Edge 内置 AI、DuckDuckGo、Google Workspace 等大量平台。它引发了一场争论：有人质疑公司强制推出没人想要的功能，也有人反驳说很多普通人确实在用 ChatGPT 替代搜索；还有人认为关键不是支持还是反对 AI，而是个人控制与选择，比如 Word 里那个发光动画的 Copilot 按钮让人无法忽略。

陈序: 评论区对这个问题吵得很厉害，核心就是"到底有没有人想要这东西"。有人说这是公司强推没人想要、还运营成本高昂的功能，市场可能长期不理性；另一派反驳说，也许很多人讨厌 AI 却还是在勉强用，公司策略就是让 AI 侵入生活、让你跑不掉，回退成本高到谁都不想回头。

林岚: 也有人举反例，说很多普通人就是用 ChatGPT 替谷歌搜索，还有人朋友拿它规划假期，并不是勉强在用。还有一派的观点更有意思：没人用反而是最理想的结果——这些功能是以不增加消费者成本的方式加进来的，目的是先从投资者手里拿钱；用户一旦真的用起来，就会产生持续的成本。但马上有人提醒，投资者迟早要分红，把钱砸进没人要求的项目最后很难看。

陈序: 另外还有一种解读，说这也是一种防御：如果用户都拿 ChatGPT 去自动化跟企业软件的交互，那些产品就沦成接大模型的管道，数据锁定战略就受威胁了；让用户用自家 AI 工具，产品才更粘性。

林岚: 还有人提到 ChatGPT 周活跃用户已经接近十亿，确实很多人喜欢用；于是有人把问题重新框定成：关键不在支持还是反对 AI，而在个人控制与选择。他自己用 Claude 体验好，因为能自己决定什么时候用；可 Word 里那个发光动画、还老是叠在屏幕上的 Copilot 按钮就荒谬透顶，不想看到也没法忽略。最后还有人抬杠说，"没人想要"这套说法能不能被证明，对方就反问，那就证明他们真的想要吗——至少他自己不想要邮件客户端主动往编辑区里填随机内容，也不希望屏幕上每条信息都被持续传到公司云服务器上被画像监视。

林岚: 这周一八月十七号，GitHub 出了点不小的状况，多项核心服务一起趴窝。有用户在 Hacker News 上第一时间贴出了报错信息，说目前没有服务器能处理你的请求，请刷新重试。有意思的是，他发帖那会儿，GitHub 的官方状态页上还是一片空白，什么都没有记录，页面是过了一会儿才挂出事故通告的。

陈序: 对，另一个用户也吐槽，说状态页当时显示一切正常，可实际上完全不是那么回事。官方后来补上的时间线显示，从下午一点四十分开始调查部分服务性能受影响，之后 API 请求、Actions、Webhooks 都被标记为性能下降，再过几分钟，又更新说 Pull Requests、Issues 这些常见操作大概有百分之二十的错误率。

林岚: 评论区里症状那叫一个五花八门。有人尝试合并 Pull Request，直接冒出错误提示说合并状态加载不出来；也有人发现代码改动一开始看不见，后来整个仓库都打不开了；还有不少用户撞见那个粉色的独角兽错误页面。更逗的是，有个用户注意到创建 issue 的接口其实还能用，但 Webhooks 一点都没触发。

陈序: 评论里还有人点破了一个细节——状态页最开始是全绿的，大概过了五到十分钟才开设这个事故条目，而且似乎是手动把服务标成性能下降的。这引来了吐槽，有人觉得把服务彻底挂掉说成性能下降挺好笑的，还有人补充说这种标记好像不算进可用性统计里，Issues 明明被标成降级，页面却还写着百分百可用时长。

林岚: 不过更正经的讨论落在了 GitHub 的可靠性上。有人觉得 GitHub 向来是开源代码的中央枢纽，这种承诺最近没兑现，他把现状比作当年 Twitter 那个著名的 Fail Whale 时代——增长没管好，但那时又没别的选择。另一个人不这么看，说单位往往是团队或组织，可以随时换平台，他自己就打算把个人项目迁走。

陈序: 还有人觉得 GitHub 难以取代但并非不可能，毕竟它是地球上最大的开发者社交网络。有人提到基于 Bluesky 那个 AT 协议的一个去中心化方向，说联邦化的思路可能对，但自己还不是用户。也有老资历提醒，当年 SourceForge 就是被 GitHub 挤下去的，说明新东西至少能削弱它。至于谁有希望接棒，有位网友直接放话——反正不会是 GitLab。

林岚: 德国联邦卡特尔局这周宣布，苹果要改变应用提供商在 iPhone 和 iPad 上拿用户数据做个性化广告的规则。这家反垄断部门反对的是苹果对待自家产品和第三方应用的方式不一样：按苹果那个跟踪透明度框架，第三方应用除了要拿到法律要求的同意，还得走苹果预设的提示多征一次同意，可这个规则偏偏不适用于苹果自己的产品，因为苹果用自家生态系统的数据，用自己的提示就过了。

陈序: 结果苹果没有上诉，反而主动提出了一堆承诺，现在这些承诺已经是强制性的，整个程序也就到此结束。主管局主席的表态是，确保个人数据和隐私得到有效保护是关键。不过 Hacker News 上讨论得可没那么客气，有人直接指出问题所在——监管只要求第一方和第三方被平等对待，却没规定怎么平等，结果苹果选了降低第三方的门槛，而不是提高自己这头儿，这等于把用户隐私的整体下限给拉低了。

林岚: 还有人翻出旧账，说苹果对自家应用和第三方应用长期搞双标。比如设计指南要求最低颜色对比度，不达标就拒绝上架，可 iMessage 绿色气泡配白字这个组合明明就被指出不达标，却一直没人管。也有人分享说，自己在日本苹果店结账，店员引导用商店应用扫码，应用接着就要分享一大堆信息，主按钮写着马上分享，底下那行小字才藏着定制选项。

陈序: 另一条线在聊监管分工的问题。有人指出竞争法部门只管把竞争环境拉平，并不关心是往上拉还是往下拉；同时欧盟在数据保护法的执行上对大科技企业一再失手，认真执行法律本意的公司反而像在针对竞争对手，爱尔兰更是被称作 Facebook 的钉子户。还有人对苹果自带应用的权限耿耿于怀，觉得它们享有别的应用必须申请才能拿到的权限，这个问题得解决。

林岚: 数据库圈这周有个大新闻，DuckDB 团队发布了新的大版本 v2.0 预告，代号很有意思，叫 Cyanoptera，是美洲西部一种红褐色水鸭的名字，预计今年秋天正式发布。文章的作者是 Mark Raasveldt 和 Hannes Mühleisen。这个版本号称要开启一句很响亮的口号——DuckDB 作为服务器的一年，带来全新的 SQL 解析器、新的默认存储格式，还有重新设计的 C API。

陈序: 重点说说服务器模式，这是整个版本的重头戏。以前想远程用 DuckDB 得靠变通写法，现在可以用新的 CONNECT 语句直接连上任何支持的远程数据库，把查询路由过去。更厉害的是新的下推优化器能把 SQL 直接推到 PostgreSQL 和 MySQL 上执行，而不是把整张表拉到本地。文章还强调，DuckDB 从一开始就是完整支持事务和多连接会话的数据库，在很多工作负载上速度足以和通用数据库正面竞争。

林岚: 另一个主角是叫 VARIANT 的类型，在上一版就推出了，被形容成加强版 JSON——每一行可以装形状完全不同的数据，DuckDB 会自动探测半结构化数据里隐藏的共同结构，把它切碎，这样不用提前声明表结构就能做到好压缩和快查询，特别适合实时日志摄入。v2.0 把这条链路从存储到扫描完整打通了，还支持在 Parquet 文件里读写。文章说计划等之后再让常规的 JSON 类型也由它来支撑，不过这个不打包票。

陈序: Hacker News 上对这份预告的反应也挺热。有人觉得过去一年 DuckDB 的这些增强，就像是在一步步铺垫往云数据仓库的方向走，虽然创始团队以前明确说过不愿意做这件事。另一个人说自己已经长期拿 DuckDB 的商业托管版当数据仓库用，一点不后悔。还有人提到 SQLite 的对比，说 SQLite 几乎没有类型系统，不太适合长期存储或者多个应用要访问的数据，日期时间尤其容易踩坑，更适合单个应用保存状态。

林岚: Hacker News 上有一篇 arXiv 论文火了，标题大意是《Rust 中的 GPU 卸载：可移植、安全而且快》。论文的核心主张是，他们搞出了一个自称零开销、支持多家厂商 GPU 的编译框架，而且原生内建在 Rust 编译器 rustc 和 LLVM 后端里。简单说，就是借着 Rust 的类型系统、所有权系统和那条严格的 noalias 别名保证，再借助 LLVM 的 Offload 基础设施来管理数据转移，还引入了一条两遍编译的流水线，去应对主机和设备目标之间各厂商 ABI 不匹配的问题。作者说，在 RAJAPerf 基准套件上，生成的 GPU 内核性能可以对齐那些原生手工优化过的 CUDA 和 HIP 的 C++ 基线。

陈序: 这个听起来确实有点诱人，因为作者说以前编程要么就得用被厂商锁定的 DSL，要么就逃到显式的 unsafe 裸指针。评论区里第一个实际的问题就是，代码到底发没发出来？有评论问摘要里找不到代码，马上就有人回应说，这东西其实是 Rust 代码库的一部分，还贴了 rustc 开发指南里关于 offload 的文档链接，以及对应的 GitHub 议题。

林岚: 还有一个人引用了论文里的一句话，说之前的 rust-gpu 项目不得不模拟指针，论文认为这对大多数高性能计算基准来说是个阻塞性的大问题。这个评论就问，为什么算阻塞问题，他觉得这本来就和 rust-gpu 的目标一致。另一个评论接话解释，说在现有的设计模式下，高性能计算目标要做高性能内存管理，确实是需要指针的。还有一个声音提到 Julia 在这一类问题上设计传承不错，关键还是让编译器去消除边界检查。

陈序: 评论区后半段也有点跑题但很热闹。有人感叹很多人把 GPU 卸载搞复杂了，马上有人反问具体复杂在哪，还有人问，简单做法是不是干脆把 CUDA 直接链接进 Rust 二进制文件里。更有一个人直接贴出了关于 GPU 通过 vsock 传输的文章链接。

林岚: 还有一个比较技术性的横向比较，有人问 Rust 加 GPU 卸载相比 Mojo 怎么样。回答是，Mojo 到现在还没完全开源，但终究会开源。不过提问的人坚持说，Mojo 开源与否并不妨碍评估它的内存模型，也不妨碍自己写内核然后跑基准测试。这个话题反正把性能和便携性这两个老难题又摆回桌面上了。

陈序: 接下来有一条关于 Linux 手机的进展，来自 Catcrafts 的一篇发文。说的是，PostmarketOS 在 Fairphone 6 上现在总算支持主摄像头了。作者是在别人此前完成的广角镜头驱动基础上写出主摄驱动的，并且让自动对焦和色彩校正一起工作起来了。

林岚: 不过这个支持还是相当初期的状态。作者自己说色彩校正还在完善，画面依旧有颗粒感，Plasma 相机以 JPG 存储也没帮到画质，他承诺会继续做降噪。和三星 Galaxy A16 的安卓样张一比，还有大量工作要做。历史上游合并的方式倒是已经商定好了：原广角驱动的作者负责提交，他负责审核和协助。

陈序: 文章里还提了几个值得注意的时间节点。作者申请了紧急呼叫测试，而且获批了，时间定在 8 月 18 日周二下午一点半到两点一刻，目的就是验证这台 Linux 手机能不能真的拨通紧急号码。另外，Fairphone 6+ 已经正式发布了，作者计划一上市就花 650 欧元买一台来做测试和修复。

林岚: 作者还透露了个更长期的想法：打算把 Catcrafts 注册成荷兰的非营利组织，当地叫 stichting。这件事取决于法律流程，如果真成了，他的薪资会公开，而且按荷兰法律，非营利组织薪资上限是市场水平。他还说欣赏 Fairphone，但一直对它的营利性质、以及对它还在马斯克的 X 上发帖这件事保留态度。

陈序: HN 评论区就因为这个激烈起来了。有人说得很难听，说这是“安卓 1.0 之前”的水平，还拿 Pinephone Pro 举例说，之前连最基本的电话功能都做不好，Linux 手机项目整体大约落后 15 年，补丁长期没人理会。马上有人用 50 欧元的二手 OnePlus 6 反击，说 Plasma 移动版相当好用，还说自己用 Kimi 和 DeepSeek 这些语言模型协助修好了安全应用里 NFC YubiKey 的毛病，附上了 GitHub 补丁。对方随即回击说，靠大模型做出来的代码，是不可维护、破坏气候、满是 bug 的烂摊子。

林岚: 后面争议就从摄像头落到了整个生态的判断。有人自 2019 年起日常用 Ubuntu Touch，但他也承认那底层还是安卓内核，大家其实在按完全不同的标准说话：用户空间、内核、完全自由软件、开放硬件，这些根本不是一回事。有人坚持严肃项目只有 GrapheneOS，还说它以后会官方支持新一代摩托罗拉旗舰，只是仍然缺现代的电话和联系人替代方案。还有人悲观地判断，谷歌收紧控制之后，AOSP 正快速走向死胡同。

陈序: 最后还有个争议有很实质的技术内核。有人推测 Fairphone 是被芯片厂商的 NDA 保密协议卡住了，主线 Linux 支持难，根本原因在厂商的闭源驱动。马上有人反驳说，官方固件本身也是靠各种 hack 拼出来的，安卓生态的驱动你根本不会想要。不过另一个角度的反驳更苛刻：他说 Murena、Jolla、GrapheneOS 这些项目就有能力做，批评 PostmarketOS 和 LineageOS 的补丁常常没人合并，最后甩了句“欢迎来到自由软件的世界”。

林岚: 最后这条来自 Fabien Sanglard 的一篇文章，讲的是 Quake 的共享版光盘——《雷神之锤共享版，一张装满得刚刚好的光碟》。它的核心点，就是当年 Quake 共享版那张 CD-ROM 塞得满满当当，几乎一点空闲空间都没剩下。

陈序: HN 评论区讨论的重点很有意思，是在质疑一个概念：把这种把内容塞满光盘的技巧叫“通过隐藏来安全”的公然混淆，到底公不公平。有个评论说，照这个逻辑，真正的对称加密不也一样吗？它本质上还是用一串被隐藏的密码或密钥，去跟别的字节做交换嘛。

林岚: 这其实就是在追问“通过混淆获得安全”和正经加密之间的那条线到底画在哪。评论者想说，如果一张塞满、没法简单再往里面塞东西的光盘也算安全通过隐藏，那对称加密里的密钥保护是不是也该被同样地归到这一类去。这个话题在评论区就是这么被一层层往下追问的。

林岚: 好，今天的内容就到这里，感谢你一直听到最后。希望这些信息对你有用，也欢迎随时回听这期节目。

陈序: 那就先陪你到这，咱们下期再见，保重。