最新

我知道 Git 并非设计成 GitHub 这种运作方式，而伪造问题由来已久，多年来一直被提及。 随着 Shai Hulud 和 AI Agent 的出现，这次情况变得更加严重，因为如果你没有启用 Vigilant Mode 并且没有注册 GPG 密钥，提交验证也可能被伪造。 我理解平台和 Git 本身存在局限性，但设计决策和设计缺陷是完全不同的两回事。 由于令人沮丧的漏洞赏金报告被驳回，以及 MSRC 将提交验证品牌化为缓解方法的讽刺意味，我等了很久才在这里发布。 GitHub 显然有机会进行与平台身份验证令牌和用户注册电子邮件关联的验证，但他们选择了不这样做。 更有讽刺意味的是，当我在等待更多关于这个问题的参与时，他们（GitHub）被黑了，这与这次黑客事件看起来是多么的巧合，简直是无价之宝。 以下是正式内容： --------------------------------------------------- GitHub 自己的文档建立了一套信任假设，如果遵循其逻辑结论，就会揭示一个无法审计、无法以编程方式检测，并且任何拥有免费 GitHub 帐户的用户都可以利用的验证漏洞。 文档中的链条： 1. GitHub 文档指出，提交签名验证让其他人“确信更改来自可信来源”： https://docs.github.com/en/authentication/managing-commit-signature-verification 2. 验证检查提交是否使用注册到 GitHub 帐户的 GPG/SSH 密钥进行签名： https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification 3. Git 每次提交都有两个身份字段：作者（编写代码的人）和提交者（应用代码的人）。两者都可以通过环境变量自由设置——GIT_AUTHOR_NAME、GIT_AUTHOR_EMAIL、GIT_COMMITTER_NAME、GIT_COMMITTER_EMAIL： https://git-scm.com/book/en/v2/Git-Internals-Environment-Variables 4. GitHub 的 UI 突出显示作者。提交者隐藏在次要点击后面。绿色的“已验证”徽章位于作者的姓名和头像旁边。 5. GitHub 的验证仅绑定到提交者的密钥。作者字段未经过验证、未经过校验且未受约束。API 直接公开了这一点——作者、提交者和验证是每次提交的单独对象： https://docs.github.com/en/rest/git/commits 逻辑缺陷： 徽章在作者姓名旁边显示“已验证”——但它验证了提交者的密钥。这可以是两个完全不同的人。GitHub 自己的 API 证实了这一点：提交可以返回 author=torvalds, committer=<ANYONE>, verification.verified=true。UI 显示 Linus Torvalds 并带有一个绿色的复选标记。签名密钥是我的。 这并不是加密方面的错误。GPG 签名是有效的。缺陷在于“已验证”所传达的内容与其实际检查的内容之间的差异。 GitHub 知道这一点——并将防御措施限制在受害者身上： GitHub 实际上有一个“部分验证”徽章状态。当作者 ≠ 提交者并且作者启用了警戒模式时，它会触发： https://docs.github.com/en/authentication/managing-commit-signature-verification/displaying-verification-statuses-for-all-of-your-commits 这意味着 GitHub 意识到作者-提交者不匹配是一个信任问题。但防御是选择加入的，默认情况下是关闭的，并且取决于被冒充用户的帐户设置——而不是攻击者的设置。攻击者通过选择尚未启用警戒模式的受害者来控制防御是否启动。Linus Torvalds 还没有。大多数 GitHub 用户也没有。

将 Notion 页面嵌入任何网站。轻松嵌入到最受欢迎的 CMS 中，无论是 WordPress 还是 Wix。