给软件开发者准备的优质简报，每日阅读 10分钟。
Who owns the code Claude Code wrote?
AI生成代码的所有权归属：开发者需要了解的法律现实
- 版权法基本规则：版权仅保护有人类创作贡献的作品，Thaler案确认纯AI生成内容不具版权资格；"有意义的人类作者身份"判断标准尚未量化，具体体现为架构选择、拒绝决定和输出重构等实质性创意决策，而非仅提供目标描述
- 雇佣合同中的IP归属：职务作品原则自动将员工在工作范围内用AI工具生成的代码归属雇主；若合同包含"公司许可工具"等宽泛IP转让条款，雇主可能主张员工使用公司许可AI工具开发的个人项目权利，即便代码生成于下班时间和个人机器上
- 训练数据许可污染风险：AI编程工具训练数据包含GPL/LGPL等著佐证许可证代码，若生成结果大量复制原代码可能导致相同许可约束，触发开源义务；"我不知道"不构成有效抗辩，且无工具可验证AI输出是否落入此风险区间，chardet社区争议和GitHub Copilot诉讼均指向这一未决问题
- Anthropic自身困境：Claude Code源代码泄露事件中，Anthropic工程师公开承认该代码主要由AI生成，Anthropic据此发出的8000份DMCA删除通知可能缺乏法律效力，凸显即便开发AI工具的公司也难以清晰主张AI主导生成代码的版权
- 开发者应采取的四项行动：使用FOSSA/Snyk/Black Duck扫描代码库许可风险；保留包含架构决策和拒绝理由的详细提交记录作为人类创意贡献证据；仔细阅读雇佣合同IP条款确认个人项目边界；商业用途时选择Anthropic API或企业级协议以获得完整IP赔偿保护
- 法律现状分化：人类创作要求、职务作品原则、著佐证许可证义务已属确定规则；代理工作流中人类参与程度门槛及AI输出复制训练数据是否构成侵权尚无直接判例；此类未决问题当前主要体现在M&A尽职调查和机构融资中，已被列为交易完成的条件之一
Zed 1.0
Zed 发布 1.0 版本：代码编辑器迎来重要里程碑
- Zed 从零开始构建，放弃 Chromium/Web 技术路线，采用类似电子游戏的方式开发，整个应用围绕 GPU 着色器渲染构建，并使用 Rust 语言从零编写了专属 UI 框架 GPUI，掌控技术栈的每一层
- 经过五年开发，代码量已超过百万行，完整支持数十种编程语言及其生态系统，涵盖 Git 集成、SSH 远程开发、调试器、彩虹括号等功能，同时支持 macOS、Windows 和 Linux 三大平台
- Zed 被定位为 AI 原生编辑器，内置多代理并行运行能力、按键级别的编辑预测功能，并推出 Agent Client Protocol 协议，已支持 Claude Agent、Codex、OpenCode 和 Cursor 等主流 AI 代理
- 宣布推出 Zed for Business 企业版，提供集中计费、基于角色的访问控制和团队管理功能，方便企业向工程团队部署推广
- 正在开发 DeltaDB 同步引擎，基于 CRDTs 技术实现字符级别的变更追踪，使多个开发者和 AI 代理能够共享同一个一致的代码库视图
- 1.0 版本意味着 Zed 已达到临界点，大多数开发者能快速上手，官方强调这不代表"完成"或"完美"，而是邀请之前因功能缺失而放弃的用户重新尝试，未来将保持每周发布节奏
Bugs Rust won't catch
Rust 无法捕获的漏洞：uutils 核心工具安全审计启示
- Canonical 于 2026 年披露 uutils（Rust 重写的 GNU coreutils）中存在 44 个 CVE，这些漏洞均未被 Rust 编译器、clippy 或 cargo audit 检测到，揭示了 Rust 安全保证的实际边界；作者强调这些审计结果对于理解 Rust 系统编程的安全边界具有重要参考价值
- TOCTOU（时间检查与时间使用）漏洞是最主要的安全问题：路径在两次系统调用之间可能被攻击者替换为符号链接，导致特权操作作用于错误目标；修复方案包括使用
OpenOptions::create_new()原子性创建文件、优先基于文件描述符而非路径进行操作、以及使用fs::canonicalize()将路径解析为真实绝对路径后再进行比较 - 权限管理需在创建时完成：在文件创建后再调用
set_permissions()会留下窗口期，应使用OpenOptions::mode()或DirBuilderExt::mode()在创建时直接设置所需权限；同时应在跨越信任边界前（如chroot调用前）解析所有用户输入，防止攻击者通过动态库注入代码执行 - Unix 边界处需区分字节与字符串：Rust 的
String/&str强制 UTF-8 编码，但 Unix 路径、环境变量和工具输入本质是原始字节，应使用OsStr、Path或Vec<u8>/&[u8]类型避免数据损坏；处理不可信输入时应将所有unwrap()/expect()替换为错误返回而非 panic，防止进程终止导致的服务中断 - 与原版工具的行为一致性本身是安全特性：重新实现成熟工具时，行为差异可能造成严重后果（如
kill -1的实现差异会将信号发送给系统所有可见进程）；任何偏离原版的行为都可能被依赖原版行为的脚本错误使用，因此 bug-for-bug 的兼容性是必要的安全措施 - Rust 确实防止了缓冲区溢出、使用后释放、双重释放、数据竞争和空指针解引用等内存安全问题（相比之下 GNU coreutils 近年多次因此类漏洞发布 CVE），但代码逻辑层面的缺陷——特别是涉及路径、字节和系统调用边界的部分——仍需依靠开发者自行规避
Talkie: a 13B vintage language model from 1930
Talkie：基于1930年前文本训练的130亿参数复古语言模型
- Talkie由Nick Levine、David Duvenaud和Alec Radford于2026年4月发布，是目前已知最大的复古语言模型，拥有130亿参数，基于2600亿个1930年前英文token训练，同时发布基础版talkie-1930-13b-base和基于历史文本后训练的对话版talkie-1930-13b-it
- 复古语言模型天然具有"无污染"特性，可用于评估模型预测未来的能力、研究数据污染问题、探索模型在无数字计算机知识下学习编程语言的泛化能力，以及回答"现代模型相似性究竟源于语言本身还是训练数据"这一根本问题
- 训练面临三大核心挑战：时间泄露风险（需确保无1930年后信息渗入语料）、OCR转录质量低下（传统系统效率仅为人工转录的30%，正则清洗仅能恢复至70%）、缺乏现成的后训练数据（无法使用现代指令微调数据）
- 团队开发了复古后训练流程，从礼仪手册、信件范本、百科全书等结构化历史文献生成指令对，使用Claude Sonnet 4.6作为评委进行在线直接偏好优化，指令-following评分从2.0提升至3.4（满分5分）
- 与同架构的现代双胞胎模型（基于FineWeb训练）对比，Talkie在知识评估上存在差距（剔除时代错位问题后差距缩小约一半），但在语言理解和数学能力上表现相当；团队正开发复古OCR系统并计划扩展多语言语料，目标是训练GPT-3.5级别的更大规模复古模型
We need a federation of forges
我们需要一个 forge 联邦
- GitHub 等单一平台存在脆弱性，全球 90% 的开源软件依赖一个提供商，去中心化技术（email、git、IRC）才能经受时间考验
- 代码协作始终依赖两个协议：代码传输协议和通信协议，经历了从 git+email 到 git+GitHub 网站，再到 git+ActivityPub（ForgeFed 项目）的演进
- Tangled 采用 git（代码传输）+ AT Protocol（通信协议）的组合，在 git 服务器（称为"knots"）之间联邦化事件，支持跨服务器协作、fork 和 pull request
- 用户可以从自有服务器推送代码后向其他服务器上的仓库发起 pull request，这种体验类似于自建 cgit 实例并通过邮件发送补丁
- AT Protocol 用于传递代码相关事件（issue、pull request）、实现社交功能（时间线、关注、star），并支持协作者邀请和 SSH 公钥共享，其余功能均依赖标准 git 协议
Before GitHub
GitHub 出现之前的开源世界
- 作者的开源基础设施演变史：从 SourceForge、自托管 Trac 和 Subversion、Bitbucket，最终迁移到 GitHub，每个阶段都是当时开源社区的典型选择
- GitHub 之前的开源是一个更小的世界：项目数量有限，每个依赖都是有历史、网站、维护者和发布流程的实质存在，添加依赖意味着真正理解其来源，社区审核机制（如 Debian 打包规范）把关信任
- 分布式版本控制系统 Git 的讽刺结局：理论上应该减少对单一中心的需求，但最终却让全世界集中在一个巨大的中心化服务上
- GitHub 的核心贡献不仅是降低参与门槛和简化协作流程，更无意中成为了一座"图书馆"——即使被遗弃的项目、Issues 和讨论始终可被找到和追溯，这种可发现性源于其中心化地位
- 微依赖问题的根源在于 GitHub 和 npm 的托管基础设施消除了创建、发布、发现和依赖的几乎所有成本，使包依赖图的增长速度超过任何人的理解能力，但也让开源更加包容
- GitHub 衰落的表现：产品迭代不稳定、AI 噪音、领导层缺失，重要开发者开始迁移（如 Ghostty、Strudel 宣布离开），但回归多 forge 模式可能让网络再次遗忘——Issues、讨论、安全公告和旧发布包都很脆弱，比代码本身更容易消失
- 社区需要建立具有公共资金支持的档案馆来保存源码、发布物、元数据和项目上下文，不再依赖单一公司的商业模式或领导层情绪
HERMES.md: Anthropic bug causes $200 extra charge, refuses refund
Git提交信息中的"HERMES.md"触发计费路由漏洞
- 当git提交消息中包含大小写敏感的"HERMES.md"字符串时，Claude Code会将API请求错误路由到额外用量计费，而非Max订阅计划配额，导致用户被扣除$200.98
- 触发条件精确为"HERMES.md"字符串本身（需同时满足大小写敏感和.md扩展名），磁盘上存在同名文件、"hermes.md"小写或"HERMES.txt"等变体均不会触发此问题
- Anthropic工程师确认根因是服务器端"过度活跃的反滥用系统"（overactive anti-abuse system），于2026年4月25日当天完成修复
- Anthropic最初以"无法为技术错误导致的错误计费提供补偿"为由拒绝退款，引发社区大量批评，部分用户因此取消订阅
- 后续有用户证实Anthropic已向受影响用户提供全额退款加$200额外credits的补偿
- 此bug难以诊断，错误信息仅显示"out of extra usage"，无法提示内容路由异常，且任何包含该字符串的git历史记录都会持续影响后续请求
Soft launch of open-source code platform for government
荷兰政府开源代码平台软启动上线
- 荷兰政府统一开源代码平台 code.overheid.nl 正式软启动上线，旨在政府范围内集中发布和开发开源软件
- 平台完全自托管，支持数字主权，采用 Forgejo 作为技术基础——这是 GitHub 和 GitLab 的开源、欧洲化且具有主权属性的替代方案
- 目前处于试点阶段，并非所有政府组织都已接入，目标是发展为政府机构共享的 Git 平台，欢迎开发者贡献代码
- 平台由内政与王国关系部（BZK）开源软件项目办公室牵头，与 DAWO（SSC-ICT）、Opensourcewerken 及 developer.overheid.nl 合作建设
- 有意参与的单位可通过电子邮件 codeplatform@rijksoverheid.nl 联系咨询
Copy Fail – CVE-2026-31431
Copy Fail（CVE-2026-31431）：2017年至今所有Linux发行版的100%可靠性内核本地提权漏洞
- 漏洞定位：CVE-2026-31431，
authencesn加密算法中的直线逻辑缺陷（非竞争条件），通过AF_ALG接口和splice()系统调用，使页面缓存页面错误进入可写分散聚集列表，导致4字节越界写入；单次执行100%成功，无需内核调试功能或预置原语 - 极简利用：732字节Python脚本（
copy_fail_exp.py），纯Python 3.10+标准库（仅需os、socket、zlib），无编译载荷、无依赖项；同一脚本通用于Ubuntu、Amazon Linux、RHEL、SUSE及Debian、Arch、Fedora等所有自2017年构建内核的发行版，默认 targeting/usr/bin/su（亦可指定其他setuid二进制如passwd、sudo、pkexec） - 极致隐蔽：写入完全绕过VFS路径，受损页面从未标记为脏页，无磁盘写入；内存压力、
drop_caches或重启后缓存重新加载干净副本，磁盘镜像与文件哈希始终保持原始值，法医取证难以发现；修复前可禁用algif_aead模块（install algif_aead /bin/false），不影响dm-crypt/LUKS、kTLS、IPsec、OpenSSL/GnuTLS/NSS等主流加密功能 - 容器逃逸原语：页面缓存在宿主机内核层共享，容器内低权限用户可利用此漏洞获得节点root权限，突破容器/租户边界；适合Kubernetes集群、CI runner（GitHub Actions/GitLab/Jenkins）、shell-as-a-service平台、多租户云SaaS等场景
- 与其他漏洞对比：与Dirty Pipe（需内核≥5.8且需特定补丁）和Dirty Cow（需竞争条件，30-80%成功率）不同，Copy Fail无任何版本检查、无偏移量调整，适用窗口横跨九年（2017→2026）
- 发现与披露：由Xint Code通过AI辅助审计Linux
crypto/子系统发现，2026-03-23报告Linux内核安全团队，04-01主线路提交补丁a664bf3d603d（回滚2017年algif_aead原地优化），04-22分配CVE，04-29公开；完整技术分析详见Xint博客，技术细节包括根本原因、分散聚集列表图解及2011→2015→2017演进历史
An open-source stethoscope that costs between $2.5 and $5 to produce
GliaX开源3D打印听诊器项目
- 由GliaX团队开发，已通过同行评审验证并在PLOS ONE期刊发表相关研究论文，性能可与市场金标准Littmann Cardiology III相媲美
- 制作成本低廉，bell部件约1-2美元，整套听诊器仅需2.5至5美元，远低于数百美元的商业产品
- 3D打印部件包含听诊头、耳管（2根）、Y型接头、弹簧和环共5个零件；非打印材料包括50cm主管道硅胶管（8mm内径/13mm外径/50硬度）、20cm耳管硅胶管（4mm内径/8mm外径/50硬度，切成两段10cm）、40mm薄膜振膜和大号耳塞
- 100%填充率打印为强制要求（低于此标准将导致声音失真），推荐PETG或ABS材料，不建议使用PLA（耐热性差、弹簧易损坏）
- 打印参数：层高0.2mm，需使用PrusaSlicer 2.0以上版本导入3MF文件
- 采用TAPR OHL开源许可证，仓库拥有839个Star、102个Fork和12位贡献者，提供YouTube组装视频及详细说明书，支持CrystalSCAD/OpenSCAD参数化设计修改
FastCGI: 30 years old and still the better protocol for reverse proxies
FastCGI：问世30年仍是反向代理的更优协议
- HTTP/1.1缺乏明确消息边界，导致desync攻击（请求走私）持续威胁反向代理安全：不同实现对同一HTTP消息可能解析出不同的边界位置，Discord等平台已因此泄露私有附件；HTTP/2虽能解决此问题，但主流代理对HTTP/2后端的支持仍不完善（nginx直至2025年末才支持，Apache仍为"实验性"）
- FastCGI本质是线缆协议而非进程模型，可直接替代HTTP用于代理与后端通信：通过TCP或UNIX套接字与长期运行的守护进程交互，Go语言仅需将
http.Serve替换为fcgi.Serve即可完成切换，handler代码完全不变 - 主流代理服务器均已原生支持FastCGI配置：nginx、Apache、Caddy、HAProxy的FastCGI后端配置方式与HTTP代理类似，以nginx为例仅需将
proxy_pass替换为fastcgi_pass并引入fcgi_params - FastCGI通过
HTTP_前缀实现客户端数据与代理可信数据的结构隔离：客户端发送的HTTP头以HTTP_前缀传输，而REMOTE_ADDR等代理可信参数则无此前缀，使攻击者无论发送何种header都无法伪装成可信数据，Go的net/http/fcgi包自动解析这些参数 - FastCGI已在生产环境验证超过10年，但仍存在不支持WebSocket、工具链不完善（curl无法直接访问）等局限：作者在SSLMate的实践经验表明"购买更多硬件远比处理HTTP反向代理的安全噩梦更划算"