?作者 | codingwoman

譯者 | 布加迪

策劃 | 言征

大家可能都會(huì)面臨這樣直冒冷汗的情形：在使用Git進(jìn)行版本控制時(shí)不小心推送了重要的密鑰或超大文件？要知道，在敏感數(shù)據(jù)公開暴露20秒后，再去刪除這些密鑰可能已經(jīng)為時(shí)太晚了！

人非圣賢，孰能無(wú)過(guò)？本文會(huì)分享介紹幾個(gè)筆者在用的好技巧，這樣在Git時(shí)，再也不用擔(dān)驚受怕了。

一、永遠(yuǎn)不要推送非必要的文件和信息

Git中一類不需要的內(nèi)容是非常大的文件。如果不小心提交了一個(gè)大文件到存儲(chǔ)庫(kù)，這肯定會(huì)限制你拉取或推送文件所需的時(shí)間；如果文件大于100MB，甚至還會(huì)顯示錯(cuò)誤。

其次，作為軟件開發(fā)圈中的一員，這個(gè)忠告應(yīng)該聽過(guò)很多次：永遠(yuǎn)不要將機(jī)密信息推送到存儲(chǔ)庫(kù)。擁有芝麻粒大點(diǎn)資源的攻擊者就可以通過(guò)竊取泄露的密文（secrets）和密鑰來(lái)危及許多GitHub用戶。然而，許多同行卻對(duì)此不太當(dāng)回事。

因此，我想分享幾個(gè)統(tǒng)計(jì)數(shù)據(jù)。

我能進(jìn)行另一個(gè)提交后刪除它嗎？

不。事實(shí)上，這比剛才的那件事還要危險(xiǎn)。不要天真地以為，當(dāng)他們從存儲(chǔ)庫(kù)中刪除文件后，文件再也訪問(wèn)不了。這正是Git的用途所在。它會(huì)跟蹤你的文件版本歷史記錄，以便你在想要恢復(fù)更改時(shí)可以恢復(fù)。

通過(guò)以下列方式進(jìn)行提交以刪除文件，你無(wú)異于將網(wǎng)上的陌生人引向存放密文的位置。

$ git commit –m “Remove api key”

只需你搜索一下，就可以看到這有多頻繁。更明確地說(shuō)，截止2023年1月5日筆者撰寫這篇文章期間，在GitHub上搜索查詢“remove api key”，返回了100萬(wàn)+提交，查詢“remove password”返回了735K+提交。

隨著ChatGPT大行其道，人們?cè)噲D編寫Python腳本來(lái)試用它，我發(fā)現(xiàn)無(wú)數(shù)的OpenAI API密鑰散布在GitHub的各個(gè)角落。

這將引發(fā)嚴(yán)重后果！

二、那該怎么辦？

當(dāng)我們考慮從Git歷史記錄中刪除提交時(shí)，首先想到的是立即將分支的頂端更改為舊的提交。這使我們安全地回到密鑰不存在于存儲(chǔ)庫(kù)中的時(shí)候。

1 $ git reset <SHA1>
2 $ git commit -am message
3 $ git push -f <remote-name> <branch-name>

1.但已有一段時(shí)間了，是否為時(shí)太晚？

好吧，如果你遇到的問(wèn)題與大文件有關(guān)，總是可以使用git filter-branch從歷史記錄中刪除過(guò)去的信息/文件。此外，還有一個(gè)極好極簡(jiǎn)單的方法，我常常使用它。

見(jiàn)識(shí)一下BFG-Repo-Cleaner！這是一個(gè)用Scala編寫的工具，可以刪除大文件（比如預(yù)訓(xùn)練的模型或無(wú)法丟棄的大PDF文件）或麻煩的blob（比如API密鑰、密碼和密文），其功能就像git filter-branch，但速度更快。

GitHub的官方推薦也建議使用BFG-Repo-Cleaner來(lái)清除文件。

說(shuō)明：我最近被告知git filter-branch已被棄用。現(xiàn)在可以使用git filter-repo或直接使用上面提到的BFG工具。

2.可以松口氣了嗎？

不，還不能松口氣。當(dāng)然，你可以隨時(shí)使用這個(gè)工具刪除大文件。然而，在將不必要的憑據(jù)推送到公共存儲(chǔ)庫(kù)之前，仍然應(yīng)該小心為好。如果你最近在GitHub上泄露了密文，應(yīng)該盡快用上面提到的工具收回密文。

此前，有一篇名為《Git會(huì)有多糟糕？揭秘公共GitHub存儲(chǔ)庫(kù)中的密文泄露》的論文首次全面深入分析了GitHub上的密文泄露。研究人員在文中評(píng)估了兩種不同的挖掘密文的方法：一種能夠?qū)崟r(shí)發(fā)現(xiàn)99%的新提交的含有密文的文件，另一種利用了覆蓋13%的公共存儲(chǔ)庫(kù)的大快照，其中一些可以追溯到GitHub創(chuàng)建時(shí)的快照。

• 你認(rèn)為大多數(shù)被發(fā)現(xiàn)的密鑰都用于測(cè)試嗎？好吧，告訴你一個(gè)可怕的消息：研究人員估計(jì)，所有發(fā)現(xiàn)的密文中89.10%是敏感信息。
• 幾個(gè)趨勢(shì)：密文減少最明顯的時(shí)候是在發(fā)現(xiàn)后的第一個(gè)小時(shí)，所有發(fā)現(xiàn)的密文中6%被移除。存在時(shí)間超過(guò)一天的密文往往長(zhǎng)期存在——第一天結(jié)束時(shí)，12%以上的密文消失了，而16天后，只有19%的密文消失了。密文和文件被刪除的速度大大超過(guò)代碼庫(kù)被刪除的速度：用戶沒(méi)有刪除代碼庫(kù)，而是創(chuàng)建新的提交以刪除文件或密文。
• 最后，最重要的結(jié)論是：發(fā)現(xiàn)GitHub上分享的密文的平均時(shí)間為20秒左右，從半秒到4分鐘不等，密文在一天中的什么時(shí)間被推送沒(méi)有任何影響。所以在你不小心推送之后，留給你彌補(bǔ)的時(shí)間，比想象的要少得多。

三、結(jié)語(yǔ)

GitHub應(yīng)該對(duì)可能暴露密文的提交，實(shí)行嚴(yán)格得多的政策或檢查。或者至少將新注冊(cè)的帳戶引到相應(yīng)的說(shuō)明文檔發(fā)出警告。筆者認(rèn)為這對(duì)于剛開始踏上編程之旅的新人來(lái)說(shuō)尤為重要。開發(fā)人員（尤其是新手）應(yīng)該知道如何安全地公開源代碼，以及忽視這么做可能面臨的后果。

如何才能避免意外提交？這里給出幾點(diǎn)建議：

• 避免使用像git add.或git commit-a這樣的catch-all命令，而是使用git add filename。單獨(dú)暫存文件也可以更好地跟蹤提交方面的更改。你總是可以在流行的文本/源代碼編輯器（比如Visual Studio Code）的源代碼控制組件中使用暫存選項(xiàng)。
• 始終查看你的文件更改。使用git diff--cached，密切關(guān)注工作樹上的變化。
• 還有其他類型的工具可以幫助你避免提交像git-secrets這樣的密鑰。
• 你還可以使用預(yù)提交鉤子。

原文鏈接：http://www.codingwoman.com/git-the-good-the-bad-and-the-ugly/