修补程序源信任与GitHub的URL层次结构

细心的读者可能在我上一篇文章中注意到GitHub补丁链接有点奇怪。我分享了Ruby的Rake构建系统的两个补丁的链接,我还说这两个补丁还没有被Rake接受。然而,这些补丁看起来像是直接来自Rake项目的官方代码库https://github.com/红宝石/耙/.那么,我是如何获得与作为项目一部分的提交/修补程序无法区分的修补程序URL的?

GitHub上的每个代码存储库首先位于用户名或组织名称下,然后位于项目名称下https://github.com/红宝石/耙/该项目是在红宝石组织的代码、问题跟踪和建议的代码更改都位于同一URL层次结构下。

建议的代码更改或“请求”是指由项目合作者或任何有贡献的人做出的建议更改。这些更改尚未得到批准并成为项目的一部分。您可以在拉/项目页面的部分,例如。https://github.com/红宝石/耙/拉/.

在里面我的文章,我在Rake项目中包含了我的补丁yabo亚博体育下载程序的以下链接。在发布时,这些补丁程序还没有被接受到该项目中。

  • https://github.com/ruby/rake/commit/f8afda2b22.patch
  • https://github.com/ruby/rake/commit/abf5e26464.patch

没有任何迹象表明我的修补程序不是Rake项目的一部分。它们与项目中的任何其他提交或修补程序都是在相同的URL方案下发布的。从URL或修补程序都无法判断代码似乎不是它们来源的项目的一部分。这些链接不应该起作用!

你可以通过社会工程欺骗某人部署一个恶意补丁程序,该补丁程序似乎合法地源自目标项目。要获得一个看起来合法的URL,只需在项目中打开和关闭一个拉取请求。大型部署程序很早就收到了关于关键安全补丁程序的提示,这并非闻所未闻恶意的源代码和意图将会公开,但是一个快速的“哎呀,那太愚蠢了。” — “诚实的错误”对拉请求的评论可能足以消除怀疑。

我第一次注意到这个问题是在对构建libjxl的问题进行故障排除时 — JPEG XL编解码器库 — 在FreeBSD上。该库的FreshPorts构建说明似乎是从GitHub上的libjxl项目获取补丁:

  • https://github.com/libjxl/libjxl/commit/adb32f3f8f.patch

为了解决我的问题,我想知道该补丁何时被接受到项目中。但是,我在项目的git日志中找不到该补丁。在进一步挖掘之后,我意识到FreshPorts软件包维护人员Jan Beich提议后又撤回由于与谷歌机器人就签署贡献者许可协议(CLA)的需要存在分歧而提出的变更请求。

在上游未能接受修复程序后,Beich将该修补程序包含在FreshPorts构建说明中。根据URL,该修补程序似乎仍然源自上游项目。从技术上讲,它是项目中的孤立提交,因为它不属于其任何分支。Beich还删除了其项目分支ect,因此提交不能显示在URL层次结构中他的用户名下。

说得很清楚,我并不是说Jan Beich做了任何恶意或错误的事情。这只是GitHub如何让您在不应该访问的URL层次结构下发布补丁的另一个例子。

GitHub甚至会不遗余力地做错事。例如,它重定向https://github.com/libjxl/libjxl/pull/193/commits/adb32f3f8f.patchhttps://github.com/libjxl/libjxl/commit/adb32f3f8f.patch。重定向会从URL中删除重要的上下文。GitHub应该改为在另一个方向强制执行重定向。但是,不属于任何分支的真正孤立的提交仍然需要一些特殊处理。

那么,您如何知道修补程序是否是项目的一部分呢?只需移除色斑来自URL的后缀,GitHub将向您显示一个包含更多信息的网页。此网页可能会说“此提交不属于此存储库中的任何分支,可能属于存储库外的分支”。GitHub可能会向您显示哪些分支和[release]标记包含此提交。

git补丁格式不允许包含不是git提交本身一部分的注释。对于GitHub来说,这可能是一种简洁的方式,可以为孤立的或不受信任的提交提供警告消息。GitHub跟踪这些信息,其网站上显示的信息就是证明。在补丁文件中无法与用户进行通信。这将离开URL层次结构 — GitHub无法充分传达补丁不是项目的一部分,不管URL层次结构如何建议。

相关阅读