Skip to content
最近，一个消息震惊开源社区：在 GitHub 上删掉的内容、私有存储库的数据都是可以永久访问的，而且这是官方故意设计的。
开源安全软件公司 Truffle Security 在一篇博客中详细描述了这个问题。
Truffle Security 引入了一个新术语：CFOR（Cross Fork Object Reference）：当一个存储库 fork 可以访问另一个 fork 中的敏感数据（包括来自私有和已删除 fork 的数据）时，就会出现 CFOR 漏洞。
与不安全的直接对象引用类似，在 CFOR 中，用户提供提交（commit）哈希值就可以直接访问提交数据，否则这些数据是不可见的。
以下是 Truffle Security 博客原文内容。
访问已删除 fork 存储库的数据
想象如下工作流程：
在 GitHub 上 fork 一个公共存储库；
将代码提交到你的 fork 存储库中；
你删除你的 fork 存储库。
那么，你提交给 fork 的代码应该是不能访问了对吧，因为你把 fork 存储库删除了。然而它却永久可以访问，不受你控制。
如下视频所示，fork 一个存储库，向其中提交数据，再删除 fork 存储库，那么可以通过原始存储库访问「已删除」的提交数据。
这种情况普遍存在。Truffle Security 调查了一家大型 AI 公司 3 个经常被 fork 的公共存储库，并从已删除的 fork 存储库中轻松找到了 40 个有效的 API 密钥。
访问已删除存储库的数据
考虑如下工作流程：
你在 GitHub 上有一个公共存储库；
用户 fork 你的存储库；
你在他们 fork 后提交数据，并且他们从不将其 fork 存储库与你的更新同步；
你删除整个存储库。
那么，用户 fork 你的存储库后你提交的代码仍然可以访问。
GitHub 将存储库和 fork 存储库储存在存储库网络中，原始「上游」存储库充当根节点。当已 fork 的公共「上游」存储库被「删除」时，GitHub 会将根节点角色重新分配给下游 fork 存储库之一。但是，来自「上游」存储库的所有提交仍然存在，并且可以通过任何 fork 存储库访问。
这种情况不是个例，上周就发生了这样一件事情：
Truffle Security 向一家大型科技公司提交了一个 P1 漏洞，显示他们意外地提交了一名员工 GitHub 帐户的密钥，而该帐户对整个 GitHub 机构拥有重要访问权限。该公司立即删除了存储库，但由于该存储库已被 fork，因此仍然可以通过 fork 存储库访问包含敏感数据的提交，尽管 fork 存储库从未与原始「上游」存储库同步。
也就是说，只要存储库有至少一个 fork 存储库，那么提交到公共存储库的任何代码都可以永久访问。
访问私有存储库数据
考虑如下工作流程：
你创建一个最终将公开的私有存储库；
创建该存储库的私有内部版本（通过 fork），并为不打算公开的特征提交额外的代码；
你将你的「上游」存储库公开，并将你的 fork 存储库保持私有。
那么，私有特征和相关代码则可供公众查看。从你创建工具的内部 fork 存储库到开源该工具之间提交的任何代码，这些提交都可以通过公共存储库访问。
在你将「上游」存储库公开后，对你的私有 fork 存储库所做的任何提交都是不可见的。这是因为更改私有「上游」存储库的可见性会导致两个存储库网络：一个用于私有版本，一个用于公开版本。
不幸的是，该工作流程是用户和机构开发开源软件时最常用的方法之一。因此，机密数据可能会无意中暴露在 GitHub 公共存储库上。
如何访问数据？
GitHub 存储库网络中的破坏性操作（如上述 3 个场景）会从标准 GitHub UI 和正常 git 操作中删除提交数据的引用。但是，这些数据仍然存在并且可以访问（commit hash）。这是 CFOR 和 IDOR 漏洞之间的联系。
commit hash 可以通过 GitHub 的 UI 进行暴力破解，特别是因为 git 协议允许在引用提交时使用短 SHA-1 值。短 SHA-1 值是避免与另一个 commit hash 发生冲突所需的最小字符数，绝对最小值为 4。所有 4 个字符 SHA-1 值的密钥空间为 65536 (16^4)。暴力破解所有可能的值可以相对容易地实现。
有趣的是，GitHub 公开了一个公共事件 API 端点。你还可以在由第三方管理的事件存档中查询 commit hash，并将过去十年的所有 GitHub 事件保存在 GitHub 之外，即使在存储库被删除之后也是如此。
GitHub 的规定
Truffle Security 通过 GitHub 的 VDP 计划将其发现提交给了 GitHub 官方。GitHub 回应道：「这是故意设计的」，并附上了说明文档。
说明文档：https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/working-with-forks/what-happens-to-forks-when-a-repository-is-deleted-or-changes-visibility
Truffle Security 赞赏 GitHub 对其架构保持透明，但 Truffle Security 认为：普通用户将私有和公共存储库的分离视为安全边界，并且认为公共用户无法访问私有存储库中的任何数据。不幸的是，如上所述，情况并不总是如此。
Truffle Security 得出的结论是：只要一个 fork 存储库存在，对该存储库网络的任何提交（即「上游」存储库或「下游」fork 存储库上的提交）都将永久存在。
Truffle Security 还提出一种观点：安全修复公共 GitHub 存储库上泄露密钥的唯一方法是通过密钥轮换。
GitHub 的存储库架构存在这些设计缺陷。不幸的是，绝大多数 GitHub 用户永远不会理解存储库网络的实际工作原理，并且会因此而降低安全性。
原文链接：https://trufflesecurity.com/blog/anyone-can-access-deleted-and-private-repo-data-github
GitHub 推出的全新功能「GitHub Models」将有望加快 AI 工程师时代的到来。
什么？大家熟悉的代码托管平台 GitHub 又进化了！该平台也开始提供 AI 大模型的 Playgroud 了。
所有你能叫得上名字的业界流行大模型，包括微软的 Phi-3、OpenAI 的 GPT-4o、Meta 的 Llama 3.1、Cohere 的 Command R+、Mistral AI 的 Mistral Large，都可以在一个交互式沙盒中试用。
在未来几个月，Github 也将添加更多语言、视觉以及其他类型的模型。
也就是说，这张图上的模型都可以「白嫖」到了！相当于又多了一个可以免费测试各家大模型的新途径！
不仅如此，开发者还可以轻松地将合适的模型导入到自己的 AI 项目中。Github 创建了一条能直接把模型放在 Codespaces 和 VS Code 开发环境中的快速通道，一下把部署 AI 模型的门槛打下来了。
这就是 GitHub 今天推出的「GitHub Models」功能！
对于开发者来说，只要有合适的工具并训练，每个人都可以成为 AI 工程师。开发者选择模型，在 GitHub 代码空间（Codespaces）中进行编码，然后通过 Azure 进行生产部署，提供了「一条龙」服务。
具体来说，你可以调用 GitHub CLI 中的 GitHub Models 命令，通过一系列 JSON 文件在 GitHub Actions 用，还可以用 GitHub Models 构建 GitHub Copilot 扩展，覆盖应用开发的全周期。
当项目迈入上线阶段时，Github 还提供了与 Azure AI 的无缝集成，Github 的身份验证可以通过 Azure 订阅，AI 应用部署到生产环境的门槛就这么被打下来了。
现在，你可以通过 Github 在全球 25 个以上的 Azure 区域部署 AI 应用，并获取 Azure 的企业级安全保护。
与 GitHub 和 Microsoft 对隐私和安全的持续承诺一致，GitHub 模型中的任何提示或输出都不会共享给模型提供者，也不会用于训练或改进模型。
当然，试玩「GitHub Models」也不是完全不受限制。个人用户每天限制访问次数 150 次，每分钟不能超过 15 次，每次请求最多可以处理 8000 个 token，最多输出 4000 个 token。
对此，GitHub CEO Thomas Dohmke 表示，该功能的推出标志着 GitHub 的又一次转型，从通过开源协作创建 AI 到借助 AI 的力量创建软件，再到如今利用 GitHub Models 推动 AI 工程师的崛起。
并且基于 OSS 存储库、Copilot Extensions 和 GitHub Models 功能，GitHub 希望将尽可能多的合作伙伴引入到自己的平台。
有开发者展示了在 GitHub 的代码空间中直接运行模型的案例，不需要安装什么东西，几秒内就可以启动。
图源：https://x.com/DanWahlin/status/1819113874689610133