GitHub原始碼外流，被公布在GitHub上，上傳使用者的名字竟還是GitHub的CEO？

最近，一位開發者Resynth1943發現，全球最大的開源程式碼託管網站，GitHub的原始程式碼已經被人上傳到GitHub自己的DMCA倉庫中被公開。

不過，GitHub的CEO Nat Friedman隨後跳出來表示，這事的確是真的，不過，也沒有大家想的那麼嚴重。

▲ Nat Friedman

什麼是DMCA倉庫？

首先要注意的就是，這個不知名的人士上傳程式碼的位置，他不是在GitHub上開了一個專案，然後把程式碼上傳上去，而是上傳到DMCA倉庫去。

身為全球最大的開源程式碼託管網站，GitHub上擁有許多原始程式碼專案。在這上面有許多來自各方軟體工程師主動提供，其中包括前陣子受到美國唱片音樂協會因為抗議侵權而關閉的YouTube下載工具的專案Youtube-dl。

這些因為被種種版權原因被命令封禁的程式碼專案封起來之後，GitHub還會將事件經過，依照時間順序記錄在GitHub中一個叫「DMCA倉庫」的地方，DMCA指的是「數位千禧年著作權法」。

比方說Youtube-dl被關閉，你可以在這裡找到相關RIAA協會寄來相關的法律文件，要求他們移除該專案的內容。

不過，Youtube-dl專案的被關閉，看來惹惱了某些人。因此，才會有人把GitHub的原始程式碼上傳到這個地方。再加上上傳的時機，因此一般認為，這個舉動是針對Youtube-dl專案的被關閉而進行的報復。

GitHub 企業伺服器 != GitHub.com

GitHub的CEO Nat Friedman，則對上傳的原始程式碼進行了說明。

根據Friedman的說法，被上傳的其實是GitHub企業伺服器程式碼，而不是GitHub網站本身。雖然兩者共用了相當多的程式碼，但兩者的區別是很重要的。其中一部分意義在於，GitHub本身其實並沒有被駭客攻擊。

雖然GitHub和GitHub企業伺服器都不是開放的原始程式碼，但GitHub企業伺服器的原始程式碼經常會傳送給客戶，不過通常是以一種混淆的格式。根據Friedman的說法，GitHub在幾個月前，不小心向一些客戶提供了一個完整的、非混淆的內容；這就是被傾倒到GitHub DMCA倉庫的程式碼。

這些程式碼本身被上傳到GitHub的DMCA倉庫中，被當成是GitHub收到的DMCA移除請求的歷史記錄。

如何提交一份移除歷史記錄？

不過，這裡又出現另一個問題。並不是任何人都能提交移除歷史記錄給GitHub，然後就可以儲存在DMCA倉庫中的。

依照常理來說，這個可以提供移除歷史記錄的人，應該要是GitHub的管理員，或是官方人員，才能夠決定是否移除一個專案，並提供移除歷史記錄才對。

事實也是如此。

而出問題的這個原始程式碼本身，根據提交的標記，是由使用者「Nat」所提交。

Nat指的正是Nat Friedman，也就是前面所提到的GitHub現任CEO。

好了，看到這裡，你可能會想，這事如果不是Nat Friedman幹的，那麼就是有駭客盜用了他的帳戶了吧？

答案是，並沒有。

GitHub提交的機制，和電子郵件一樣，允許使用者在user.name和user.email欄位中隨意填寫任何資訊。因此，這使得你要提交假的資訊難度根本微不足道。他們的確有一個比較嚴謹的驗證，就是如果提交的內容是用與該電子郵寄地址相關聯的 GPG 金鑰簽署的，在該用戶的旁邊就會標明一個「已驗證」的標誌。

而這個所謂的「Nat」提交的原始碼，在身份旁邊並沒有標明「已驗證」，這意味著它沒有用Friedman的GPG金鑰簽名。

好了，看到這裡，你可能會想，那麼如果沒有驗證的話，這個來自阿里不達的「Nat」所提交的內容，又怎麼會出現在 GitHub 的 DMCA 倉庫中？這總是有誰洩漏了什麼帳密了吧？肯定是有內鬼？

答案是，也沒有。

由於這個部分比較有技術難度，簡要的理解就是當你把一個提交推送到 Git 時，你會得到一個代表該提交的雜湊值。為了製造GitHub CEO Nat Friedman「本人」對GitHub DMCA倉庫進行提交的假像，這個不明身份者，首先需要複製整個DMCA倉庫，對DMCA倉庫進行專案創建出一個他們有許可權可以提交的副本。然後再將雜湊值指向自己提交到這個副本的雜湊值。

也就是說，透過這種方式，雖然複雜，但是不需要攻擊性的技巧，就可以創造出一個看似由Friedman本人提交的內容。

GitHub 沒有被駭，但的確需要改進

從好的方面看，這整個事件沒有真正的問題：原始程式碼是免費提供給客戶的，而不是從被入侵的伺服器上流出的。同樣，Friedman也沒有失去對自己帳戶的控制權，GitHub也沒有失去對其DMCA倉庫的控制權。

用Friedman自己的話來講：「一切都很好，情況正常，世界和平。」

但是，這裡也突顯出GitHub對於身份驗證寬鬆問題。如果你想驗證自己的身份，就應該用GPG金鑰來簽署發佈，管理 GPG 依然繁瑣，足以成為許多開發者進入的重要障礙。但更重要的是，GitHub並沒有提供任何控制功能，來強調這種簽名的存在或缺乏。

而目前GitHub上依然允許無簽名的提交，也或許是該認真看待這件事了，今天的網路上，即便是簡單的瀏覽，人們都希望使用認證和加密來進行，GitHub的驗證方式似乎更加的令人驚訝和不安。

新聞來源：arstechnica