GitHub的源代码昨晚在GitHub网站…上泄露。说大也大吧

昨晚，开发者和隐私权活动家Resynth1943宣布，GitHub的源代码在GitHub自己的DMCA库中被泄露。要谈论这一点需要拆开一些东西，但首先要做的是--这并不是听起来那么重要的事情。

Resynth1943似乎爆料了这一消息，并称密码是由一个身份不明的人泄露的。他在Hacker News上重新发布了这一声明后不久，GitHub首席执行官纳特·弗里德曼就现身HN，提供了一些背景信息。在这之后不久，GitHub的首席执行官纳特·弗里德曼(Nat Friedman)出现在HN上，提供了一些背景信息。

根据Friedman的说法，有问题的上传实际上是GitHub企业服务器，而不是GitHub网站本身。虽然两者共享大量代码，但区别是显著的。这种重要性的部分原因在于，giHub本身实际上并未遭到黑客攻击。

虽然GitHub和GitHub Enterprise Server都不是开放源代码，但GitHub Enterprise Server的源代码通常会交付给客户，尽管通常是以精简和模糊的格式。根据弗里德曼的说法，几个月前，GitHub意外地向一些客户提供了一份完整的、非模糊的GHES文件；这是被丢弃到GitHub的公共DMCA库中的代码。

看起来很可能是因为最近YouTube-dl被撤下而引起的愤怒，所以Resynth1943提到的那个不知名的人上传了泄露的源代码。

代码本身被转储到GitHub的DMCA储存库中，该储存库是GitHub收到的DMCA关闭请求的历史记录，类似于你多年来在谷歌搜索上看到的令人不寒而栗的通知。

受Lumen(以前的寒蝉效应)和谷歌的启发，这份回购包含了我们在GitHub收到的DMCA下线通知和反通知的文本。我们一收到就公布，只对个人身份信息进行编辑。

Resynth1943；的声明同时批评微软虚伪，没有刻意公开GitHub的源代码，同时暗示，既然GitHub的代码已经泄露，它可能会变得不那么安全。

GitHub的现任首席执行官纳特·弗里德曼(Nat-aka Nat Friedman)表示，这一承诺本身显然是由用户纳特-又名纳特·弗里德曼做出的。就像提交的内容一样，这具有误导性--Git本身(GitHub底层的源代码版本控制系统)并不能很好地防止用户模仿。有问题的提交没有标记为已验证，这意味着它没有用弗里德曼的GPG密钥签名。

Git提交-与电子邮件消息非常相似-允许用户在user.name和user.email字段中输入任何他们喜欢的信息。这使得欺骗这些信息变得微不足道。除非提交的邮件实际上是用与该电子邮件地址相关联的GPG密钥签名的，否则无法真正验证它来自于它所说的应该来自哪里。

这就留下了一个问题，即某个随机用户提交的内容最初会如何出现在GitHub的DMCA存储库中--但那里的答案也不涉及任何实际的帐户泄露。

当您将提交推送到Git存储库时，您将获得一个表示该提交的散列，并可用于在树中定位它。GitHub的一部分是提供在浏览器中访问底层Git结构的Web应用程序，它将Git存储库的所有分支保存在单一的底层存储库中，尽管它在URL结构中通常不是这样显示的。

因此，为了制造一种假象，即GitHub首席执行官纳特·弗里德曼(Nat Friedman)对GitHub DMCA repo做出了承诺，这个不知名的人首先需要克隆DMCA存储库。在分叉存储库之后--创建一个他们有权提交的副本--下一步是提交泄密的来源，在user.name和user.email中伪造Friedman的名字和电子邮件地址。

这将导致一个带有虚假提交的分叉存储库。但它看起来还是不太对劲--毕竟，URL仍然会同时指向分叉和攻击者真实的GitHub用户名和账号。但在幕后，父和分支都是底层Git级别的同一个存储库的一部分。这使得攻击者可以构建一个URL，使提交看起来像是对主存储库进行的，而不是对分叉进行的。

为了完成欺骗，攻击者从https://github.com/github/dmca，开始，然后将树/$hash附加到末尾，其中$hash是对他们自己的分叉进行的提交的散列--然后就完了！结果是一个似乎是首席执行官纳特·弗里德曼(Nat Friedman)向GitHub自己的DMCA存储库提交的URL。

GitHub没有被“黑”--但还有很大的改进空间

好的一面是，这里没有真正的妥协。源代码是免费提供给客户的，如果不小心的话--而不是从被泄露的服务器中泄露出来。同样，弗里德曼没有失去对自己账户的控制，GitHub也没有失去对其DMCA存储库的控制。用弗里德曼在黑客新闻(Hacker News)上颇为轻率的话来说，一切都很好，情况正常，百灵鸟在飞翔，蜗牛在荆棘上，一切都与世界融为一体。

虽然这里记录的所有恶作剧都在预期之内-如果你想验证你的身份，你应该用GPG密钥签署你的承诺书-但这些期望本身可能比应有的要低得多。管理GPG仍然非常繁重，足以成为许多开发人员进入的一大障碍。更重要的是，GitHub没有提供任何控制来强调此类签名的存在或缺失。

我们已经看到了很多关于工具提示的建议，比如这个用户通常会在他们的提交上签名，而在适当的情况下，这个提交不会被签名。我们还认为，现在已经过了修复该问题的时候了，该问题允许攻击者使用我们上面描述的分叉和手动URL构建技术来欺骗他们承诺要使用的存储库。

最后，可能是时候认真讨论一下，未签名的提交是否应该是默认的。我们生活在这样一个世界，即使是简单的网络浏览也被压倒性地期望使用身份验证和加密进行-这使得今天看到的那种随意的欺骗变得更加令人惊讶和不安。