你的 Github 倉庫被 DMCA Takedown 後怎麼辦？

倉庫被封禁

在 2018 年 2 月 20 日，我們的開源項目放在 GitHub 上的倉庫由於收到了 DMCA Takedown 投訴被封禁，倉庫處於不可訪問狀態。此時在 GitHub 上訪問該倉庫時，會顯示一個公開消息，表明該倉庫被封禁的原因。

按照 GitHub DMCA 的規則，GitHub 在確認投訴有效後，會給該倉庫的管理員發送一封郵件，提示該倉庫需要在 24 小時內清理被投訴的內容，並回復 GitHub 才行——否則，該倉庫會被封禁，禁止任何訪問和數據導出。

我們在收到該 Takedown 投訴後，會有 24 小時的時間來響應，但由於過年期間，倉庫擁有者沒有及時看到郵件，未能及時發現這麼嚴重的通知。因此，在過了 24 小時後， Github 按照 DMCA 的規則，進行了倉庫的封禁。

倉庫被封禁後，我們發現無法訪問。根據封禁消息的提示，發現原來之前倉庫內的某個文件出了問題，侵犯了原作者的版權。原作者向 Github 發送了 DMCA 投訴。而由於我們的未及時處理，導致了倉庫的最終被封。當我們發現被封時，已經是深夜了。

緊急商討方案

在被封禁後，由於已經超過了 24 小時時限，在這個階段下， GitHub 的文檔中給出的解決方案僅有請求 GitHub 來刪除該倉庫並根據自己手裡的倉庫數據重建的方案。但對我們來說，這種方案是不可接受的，因為這種方案會導致丟失所有的 issue、PR、Wiki，以及你本地的倉庫和遠程的倉庫之間的版本差異。

我們在群內先找了更新最全的 fork，找到了一個群友提供的，和上游只差 2 個提交的版本，並將其保存下來，作為最後的自救手段。

此外，在查詢 DMCA 的過程中，我了解到 DMCA 除了有 DMCA Takedown 以外，還有一個 DMCA Counter Notice，用於反向解除 DMCA 封禁。

DMCA Counter Notice

DMCA Counter Notice 用於向服務商發起申訴，說明 DMCA Takedown 投訴為惡意投訴且並無版權問題。

延展閱讀

https://www.plagiarismtoday.com/2010/06/03/7-common-questions-about-dmca-counter-notices/

https://help.github.com/articles/guide-to-submitting-a-dmca-counter-notice/

當時考慮到我們已經錯過了窗口期，沒辦法刪除 GitHub 上倉庫中的特定文件，所以想通過 DMCA Counter Notice 來解除封禁。

為此，我通過 Github 發給我們的郵件，找到了那份侵權文件，並在他的網站中找到了版權擁有者的郵件，發送郵件說明情況，看看能否通過付費獲得授權。但其是挪威人，存在時差，所以我們只能邊等待，邊想辦法。

山重水複疑無路，柳暗花明又一村

在準備 DMCA Counter Notice 時，我們又向 Github 發送了郵件，說明了中國春節的特殊情況，導致我們沒有來得及處理文件，請求給我們一個機會讓我們處理這些文件。但是遲遲沒有回應，無奈之下，多位成員又以成員身份向 GitHub 發送郵件，請求給予幫助。

令人驚奇的是，經過大約 9 個小時的等待，倉庫擁有者的請求郵件似乎開小差了，而各位成員的請求郵件得到了響應。Github 回信給大家說，根據其規則，給出了額外的 24 小時窗口期，讓我們處理這些文件（後來經過仔細查閱 GitHub 的 DMCA Takedown 規則，對這種錯過了第一次窗口期的情況，可以給予第二個，也是最後一個窗口期）。但是這個開啟額外的窗口期，需要倉庫的擁有者向 GitHub 發送郵件請求。

然後，我們就以倉庫擁有者的身份再次向 GitHub 發送了請求，可能是由於時差的原因，又是幾個小時沒有回應。

與此同時，我們也收到了版權擁有者的回復。很遺憾，原作者不願意授權，也不打算收費。好在 Github 給的額外窗口期，讓我們有了改正錯誤的機會。

還好，在焦急的等待之中，我們終於收到了 GitHub 的回復，並同時恢復了倉庫的訪問——寶貴的 24 小時窗口期。

使用 BFG 處理文件

得到了窗口期後，我們開始處理倉庫內的文件。

首先，你得清除了現在還在倉庫裡面的文件，然後再使用下面的方面來清除提交歷史中的數據。

推薦閱讀

以下文章建議按順序閱讀

https://help.github.com/articles/removing-sensitive-data-from-a-repository/

https://rtyley.github.io/bfg-repo-cleaner/

刪除 Git 倉庫的歷史數據有多種方法，一種是使用 git filter-branch來處理，但是速度極慢。另外一種就是使用 BFG 來處理，我們採用的是 BFG 來處理（BFG 是git filter-branch 首字母的逆轉）。

BFG 需要 Java 的運行環境，如果無法運行，請檢查你的本地 Java 環境是否安裝，或高於 Java 7 。

Java 6 需要使用 bfg v1.12.3版本

BFG 的處理過程比較簡單，首先，你需要下載 BFG。

wget http://repo1.maven.org/maven2/com/madgag/bfg/1.13.0/bfg-1.13.0.jar

然後克隆你的倉庫到本地，比如 bestony/test。

git clone --mirror  git://github.com/bestony/test.git

克隆時用不用 --mirror 模式都可以，但是後續命令上會有所差距，所以我還是推薦大家使用鏡像模式，畢竟按照官方的文檔走，出現了問題也好搜索。（鏡像模式克隆的倉庫和遠程倉庫完全一樣，但是不能直接看到倉庫裡面的文件，而且也不能允許 git 的各種命令）

克隆到本地後，執行 BFG 命令來處理文件。

cd test.git
java -jar bfg.jar --delete-files "filename"

這裡需要注意的是，filename 不支持目錄路徑，只能是文件名，而不能是 dir/filename 這樣的形式，所以添加參數時你要注意這個。對於有同樣名字的文件卻想只刪除某個目錄的情況，可能就沒有辦法了。

此外，默認情況下， BFG 不會處理最新的提交，它認為你的最新提交應該是乾淨的（不包含需要刪除的敏感數據），如果你要刪除的文件是最新的提交（比如你最新的一個提交是刪除那些敏感數據），可以加入--no-blob-protection參數來強制清除，也可以再添加一個提交，使包含了要被刪除文件的提交不是最新的提交。

java -jar bfg.jar --delete-files "filename" --no-blob-protection

BFG 處理完成後，會提示你使用 git 命令進行垃圾回收，你需要執行如下命令來操作：

cd test.git # 進入目標目錄
git reflog expire --expire=now --all && git gc --prune=now --aggressive # 垃圾回收

這裡需要注意的是，如果你刪除多個文件，每次刪除後執行和多個文件都刪除後效果一樣，所以建議你刪除多個文件後再進行垃圾回收，會更省時一些。

處理完成後，將數據推送到遠端即可（需要關閉 GitHub 上倉庫設置裡面對強制推送的防護）：

git push

執行完成後，就可以到遠端上去看了，你的文件會被刪除，相關的提交不會被刪除，但是提交裡面不包含該文件了。

在推送時，可能會提示你有些更改被拒絕了，這些更改如果是和 Pull Request 有關的，你可以不需要在意，這是 GitHub 自身的問題。Github 設定 Pull Request 是只讀不可改的。所以我們無法修改這些信息。

具體可以參考 https://github.com/rtyley/bfg-repo-cleaner/issues/36

至此，我們將文件進行了刪除處理，並清除了相關的數據。

後續處理

在完成文件及歷史數據的刪除後，我們將我們的刪除結果回復了 Github ，等待 Github 的確認。GitHub 會在 24 小時收到該回復後，會通知投訴方進行確認。如果投訴方無異議，此事就此結束，不會再有下一步動作。如果有異議，則會重新進行此流程。

此外，由於 GitHub 存在垃圾緩存回收的時間差，所以你推送到 GitHub 上的數據雖然並無需要被刪除的文件，但是依舊在一定時間內可以看到。這種緩存只能請 GitHub 自行操作刪除。此外，與要刪除的文件相關的 Pull Request 也需要 GitHub 來刪除——因為用戶是沒有許可權刪除 Pull Request 的。這些請求也可以一併發給 GitHub 來操作（但似乎 GitHub 並不熱衷執行這些請求，只要被投訴的文件訪問不到即可，也就是說，如果沒有被投訴歷史數據，其實或許並不用大動干戈清理歷史……）。

這種清除操作還有一個副作用就是，所有之前 fork 的倉庫，由於主倉庫被封禁而導致各個 fork 倉庫的 remote 意外地變為另外一個倉庫（該倉庫是最早的一個 fork 倉庫）。而主倉庫恢復之後，我們並沒有找到好的辦法將 remote 恢復回原來的主倉庫。因此，需要所有成員重新 fork 主倉庫並從緩慢的 GitHub 克隆到本地。

餘思

這個驚魂事件當中，我們首先要反思的是，我們對版權問題的認識不足，這是一切問題的根源。因此，這之後，我們對既有數據進行了排查。

其次，GitHub 在這種事件的處置上，我們認為也並不夠好。這麼嚴重的處置（整個庫封禁），僅僅通過一份普通的郵件通知，而且僅僅給出 24 小時的時間窗口。而 GitHub 其實掌握了倉庫擁有者的更可靠、更及時的聯繫方式，比如說手機簡訊，也完全可以在 GitHub 的網頁界面上以顯目的方式提醒。另外，雖然 DMCA 規則中提到了可以容情第二個時間窗口，但是似乎這個附加窗口期是後來才改變的政策，在前面的流程說明中並未提及，很容易忽視。

其三，由於封禁會導致對該倉庫的所有訪問均不可進行，這不僅包括了提交數據，也包括了並沒有存在於 Git 倉庫中的 issue、PR 和 Wiki 等數據，而 GitHub 不會讓你在封禁的情況下有機會導出這些數據。所以，有機會的話，各種數據還是有個備份的好。

最後，感謝在這個事件中，所有不離不棄支持我們的成員，感謝小白進行的倉庫清理工作。

相關閱讀

• https://blog.kongfanjian.com/2015/03/02/%E6%B0%B8%E4%B9%85%E5%88%A0%E9%99%A4git%E4%BB%93%E5%BA%93%E4%B8%AD%E7%9A%84%E6%96%87%E4%BB%B6%E4%B8%8E%E5%8E%86%E5%8F%B2%E8%AE%B0%E5%BD%95/
• https://changkun.us/archives/2017/11/239/
• http://debugtalk.com/post/clean-sensitive-data-from-git-history-commits/
• http://www.voidcn.com/article/p-njmjnwov-bgk.html
• http://www.vicviz.com/githubshang-de-min-gan-shu-ju-de-shan-chu/
• https://lightless.me/archives/remove-sensitive-data-on-github.html
• http://blog.csdn.net/duandianR/article/details/78843582
• https://www.clock.co.uk/insight/deleting-a-git-commit
• https://www.jacoballred.com/web-dev/use-bfg-to-completely-remove-a-file-from-your-git-repo/
• https://community.atlassian.com/t5/Questions/BFG-for-a-Noob/qaq-p/350944
• https://w3guy.com/remove-git-commit-history/

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive