首次披露：递归克隆还没结束，恶意hook已能执行

Git submodule 常被当作“锁定到具体 commit 的依赖方案”，但它并不是真正完整的包管理器。Andrew Nesbitt 从一次 worktree 清理失败的真实经历出发，拆解 submodule 在依赖解析、安装、存储、更新与清理上的结构性缺陷：空目录、分支切换后的错误状态、失效 URL 与分散的本地状态，都会让所谓的可复现依赖变得脆弱。 本期「Andrej Karpathy的RSS订阅清单」深度解析这篇文章，并进一步聚焦其安全含义：当未经审查的 `.gitmodules` 能影响递归克隆流程，Git 的内部机制与信任边界便可能直接暴露给攻击者。欢迎结合原文阅读，理解为什么 submodule 往往需要团队自行补齐一整套包管理能力。 原文链接： https://nesbitt.io/2026/09/01/git-submodules-as-a-package-manager.html 原文标题：Git Submodules as a Package Manager 主要内容： • 将 Git submodule 视为包管理器：gitlink 相当于锁文件条目，`.gitmodules` 相当于依赖清单，`git submodule update` 则承担安装职责。 • 精确的 commit SHA 无法解决解析问题：上游 URL 变更会令依赖失效，而本地 `.git/config` 对 URL 的缓存又会让仓库中的修复无法自动生效。 • 安装与工作区状态并不可靠：普通克隆常留下空的 submodule 目录；切换分支后，子模块工作树不会自动切换到目标 commit。 • worktree 与 submodule 的组合存在长期摩擦：清理需要强制执行，移动 worktree 甚至被直接拒绝，暴露出两套机制间未被妥善处理的状态耦合。 • 安全风险来自裸露的内部机制：历史 CVE 表明，递归克隆期间对 submodule 内容的处理可能被利用，将恶意 hook 写入并在用户尚未审查代码时触发。 推荐理由： 这篇文章的价值不只是罗列 submodule 的使用痛点，而是指出一个更根本的问题：依赖生命周期、缓存、解析与信任边界缺少统一所有者。对于维护多仓库依赖、使用 Git worktree，或关注软件供应链安全的开发者来说，它提供了一种重新审视 Git submodule 的清晰框架。 --- 「Andrej Karpathy的RSS订阅清单」为您精选全球最前沿的AI技术博客文章，深度剖析技术背后的核心洞察。 由 voieech.com 提供技术支持。