譯者 | 涂承燁

審校 | 重樓

開發(fā)者中普遍存在一種誤解，認(rèn)為一旦刪除了提交（commit），它就永遠(yuǎn)消失了。你可以強(qiáng)制推送（force-push）來重寫歷史，或者刪除包含敏感信息的分支（branch），并以為它已被安全擦除。但 GitHub 和 Git 本身并不這樣工作。

事實(shí)上，GitHub 能夠以不顯而易見的方式保留并暴露“已刪除”的提交。在某些條件下，你認(rèn)為已被移除的提交仍然可以被公開訪問。這造成了一種隱私假象—開發(fā)者感覺安全了，但實(shí)際上，敏感信息的痕跡可能仍然可以訪問。

在本文中，我將逐步闡述這種情況是如何發(fā)生的，演示已刪除或私有的提交在哪些情況下仍然可以被訪問，并解釋這對(duì)注重安全的團(tuán)隊(duì)、開源維護(hù)者以及錯(cuò)誤應(yīng)用 GitHub hygiene的開發(fā)者意味著什么。

Git 如何處理“已刪除”的提交

Git 是一個(gè)分布式版本控制系統(tǒng)，用于跟蹤文件的版本。這意味著開發(fā)者可以獨(dú)立擁有自己的分支版本。

其核心在于，Git 是一個(gè)內(nèi)容可尋址的數(shù)據(jù)庫(kù)。提交（commits）、樹（trees）和 blob 對(duì)象（blobs）根據(jù)它們的 SHA-1 或 SHA-256 哈希值存儲(chǔ)。Git 并非真正“刪除”內(nèi)容—它只是取消對(duì)它們的引用。

讓我們看看這在實(shí)踐中是什么樣子：

首先，初始化一個(gè)新的 Git 倉(cāng)庫(kù)并添加一個(gè) README.md 文件。

向 README.md 添加一些更改并再次提交。

此時(shí)，我們有兩個(gè)提交。你可以用 git log 查看它們：

HEAD 是一個(gè)位于倉(cāng)庫(kù)內(nèi) .git/HEAD 文件中的指針。這個(gè)文件通常包含對(duì)當(dāng)前分支的引用（例如，ref: refs/heads/main），或者如果你處于分離的 HEAD（detached HEAD）狀態(tài)，則包含一個(gè)特定的提交哈希值。

讓我們使用 git reset HEAD^ --hard 重置（reset）到第一個(gè)提交。

我們可以看到 HEAD 已切換到第一個(gè)提交：

第二個(gè)提交消失了。這類似于你進(jìn)行強(qiáng)制推送（git push -f）時(shí)發(fā)生的情況。它可能看起來代碼已被擦除—但實(shí)際上，你仍然可以使用 git reflog 恢復(fù)它。

在這里，我們可以看到第二個(gè)提交的 SHA-1 哈希值是 2b9714e。

讓我們通過重置HEAD將它恢復(fù)。

讓我們看看提交哈希值。Git 同時(shí)支持哈希值的完整和縮短版本：

Git 中的每個(gè)提交都有一個(gè)唯一的哈希值作為其“ID”。該哈希值是根據(jù)整個(gè)提交內(nèi)容計(jì)算出來的，包括：

• 文件和目錄結(jié)構(gòu)（“樹”對(duì)象）
• 提交信息
• 元數(shù)據(jù)，如作者、提交者和時(shí)間戳
• 父提交的哈希值

Git 默認(rèn)使用 SHA-1（或可選地使用實(shí)驗(yàn)性功能 SHA-256）。你通常不需要完整的哈希值—Git 允許你使用縮短版本（通常 4-7 個(gè)字符就足夠了）。在我的例子中，是 f38b 和 2b97。

這就是 Git 本地工作的方式。

但是 GitHub 呢？這就是事情變得有趣的地方。

GitHub 呢？

GitHub 作為一個(gè)構(gòu)建在 Git 之上的分布式平臺(tái)，不僅繼承了 Git 的去中心化機(jī)制，還引入了其自身的復(fù)雜性和風(fēng)險(xiǎn)層。

讓我們重新審視之前的實(shí)驗(yàn)。

我創(chuàng)建了一個(gè)公共倉(cāng)庫(kù)并添加了兩個(gè)提交：

然后我運(yùn)行了：

我們?cè)?/span> GitHub 上看到了什么？

第二個(gè)提交消失了—從歷史記錄中擦除了。

當(dāng)然，我可以使用本地 Git 工具恢復(fù)它（如前所示），但我們還能在 GitHub 本身上訪問它嗎？

是的！

你可以直接在瀏覽器中使用以下方式訪問該提交：

對(duì)于我的例子：

https://github.com/C4tWithShell/demo/commit/cbc61bd83a87561c101a325b03ec9873a7c0cc62

GitHub 警告：

“此提交不屬于此倉(cāng)庫(kù)的任何分支，可能屬于倉(cāng)庫(kù)外部的某個(gè)分支（fork）?！?/span>

但整個(gè)提交內(nèi)容仍然可用。

公共倉(cāng)庫(kù)（Public repositories）

由于 GitHub 是一個(gè)分布式平臺(tái)，我們可以將這個(gè)想法擴(kuò)展到連接的倉(cāng)庫(kù)—上游（upstreams）倉(cāng)庫(kù)及其分支（forks）。

我能訪問已刪除分支（fork）中的提交嗎？

我分叉（fork）了我的演示倉(cāng)庫(kù)，在上面工作，并錯(cuò)誤地添加了一個(gè)新的 .md 文件。

然后我意識(shí)到了錯(cuò)誤，并通過 git push -f 刪除了它。

我不再看到那個(gè)提交了，但它真的消失了嗎？

多虧了 SHA-1 哈希值，我們可以僅用 4-7 個(gè)十六進(jìn)制字符來定位提交。只有 65,536 (16?) 種可能的組合，對(duì)于現(xiàn)代機(jī)器來說，暴力破解簡(jiǎn)短的 SHA 前綴是微不足道的，并且完全可以自動(dòng)化。

我仍然可以在我的分支（fork）中找到那個(gè)提交。即使該分支后來被刪除，我也可以從原始倉(cāng)庫(kù)訪問它。

如果上游倉(cāng)庫(kù)被刪除了呢？

好的，讓我們反過來想。

假設(shè)我向原始倉(cāng)庫(kù)提交了一個(gè)秘密（secret），然后在任何人分叉（fork）它之前立即刪除了它。我安全了嗎？

這次，為了確保，我們甚至刪除我的上游倉(cāng)庫(kù)。

刪除我的演示倉(cāng)庫(kù)后，我看到不再有“forked”的鏈接，并且我看不到 SECRET.md 文件了。

這次，我創(chuàng)建了那個(gè)分支的一個(gè)分支（fork），并使用簡(jiǎn)短的 SHA 挖掘提交歷史。這意味著我仍然可以恢復(fù) SECRET.md 提交！

因?yàn)橹灰€有一個(gè)分支（fork）存在，該提交就存在。

這怎么可能？

這是可能的，原因在于 GitHub 中的倉(cāng)庫(kù)網(wǎng)絡(luò)—倉(cāng)庫(kù)與其分支（forks）之間的關(guān)系網(wǎng)。你可以在以下位置探索它：

它顯示：

• 誰fork了該倉(cāng)庫(kù)；
• 提交如何在不同分支（forks）間產(chǎn)生分歧；
• 存在于分支（forks）中但不存在于主倉(cāng)庫(kù)中的提交。

因此，當(dāng)有人分叉（fork）一個(gè)倉(cāng)庫(kù)時(shí)，GitHub 會(huì)跟蹤父子關(guān)系。即使分支（forks）被刪除或設(shè)為私有，只要：

• 該分支曾經(jīng)是公開的；
• 在分支被刪除/設(shè)為私有之前提交已被推送。

那么，它們可能仍然在網(wǎng)絡(luò)圖（network graph）中被跟蹤。GitHub 存儲(chǔ)的提交哈希值，如果你知道 SHA，仍然可以訪問，這是一個(gè)已知的元數(shù)據(jù)泄露途徑。

它會(huì)影響私有倉(cāng)庫(kù)嗎？

讓我們用一個(gè)私有倉(cāng)庫(kù)試試。

我創(chuàng)建了一個(gè)私有倉(cāng)庫(kù)并fork了它。該分支保持私有狀態(tài)，無法將其設(shè)為公開。我在分支中添加了一個(gè)額外的文件。

即便如此，我仍然可以從原始倉(cāng)庫(kù)使用其簡(jiǎn)短的 SHA 訪問這個(gè)提交。

至少在這種情況下，可見性是受控的——分支無法公開，訪問僅限于協(xié)作者（collaborators）。

但真正的問題在這里...

我見過一些公司開源其內(nèi)部倉(cāng)庫(kù)。在這樣做之前，他們通常會(huì)徹底清理主倉(cāng)庫(kù)。

但是分支（forks）呢？

當(dāng)一個(gè)私有倉(cāng)庫(kù)變?yōu)楣_時(shí)：

• 原始倉(cāng)庫(kù)的分支網(wǎng)絡(luò)在發(fā)布的那一刻被凍結(jié)。
• 在私有分支（forks）中發(fā)布之前所做的所有提交都可能變得公開可見。
• GitHub 不會(huì)警告你這一點(diǎn)。

因此，即使你的主倉(cāng)庫(kù)是干凈的，你也可能正在暴露先前私有分支中的秘密。

讓我們測(cè)試一下。我更改了我的原始倉(cāng)庫(kù)的可見性。它只有一個(gè)干凈的提交和一個(gè)文件。

我能訪問我私有分支（fork）中的那個(gè)提交嗎？

成功！我們可以看到在原始倉(cāng)庫(kù)發(fā)布之前在私有分支（fork）中做出的所有提交。為了驗(yàn)證，讓我們向我們的私有分支添加一個(gè)新的提交：

現(xiàn)在讓我們嘗試從公共倉(cāng)庫(kù)訪問它：

為什么會(huì)這樣？因?yàn)橐坏﹤}(cāng)庫(kù)變?yōu)楣_，GitHub 就會(huì)分離倉(cāng)庫(kù)網(wǎng)絡(luò)。之后添加到私有分支（fork）的提交就變得隔離了。

這種行為是雙向的：

• 發(fā)布后私有分支（fork）中的提交從公共倉(cāng)庫(kù)是不可見的。
• 該時(shí)間點(diǎn)之后公共倉(cāng)庫(kù)中的提交從私有分支（fork）是不可見的。

這是一個(gè) Bug 嗎？

不，這是 GitHub 的一種設(shè)計(jì)行為，他們甚至在文檔中提到過。不幸的是，沒有多少人深入研究它。

閱讀下面—GitHub 關(guān)于分支（fork）的可見性說明：

當(dāng)你將倉(cāng)庫(kù)的可見性從私有更改為公共時(shí)，其每個(gè)現(xiàn)有的私有分支（fork）都將變?yōu)樗接袀}(cāng)庫(kù)，并失去對(duì)上游網(wǎng)絡(luò)的訪問權(quán)限。公共倉(cāng)庫(kù)的分支始終是公共的。

可以采取什么措施來解決它？

• 始終將 GitHub 視為公開的（Treat GitHub as Public-Always）假設(shè)你推送的任何內(nèi)容最終都可能被暴露。密鑰（Secrets）不屬于 Git。使用秘密管理器—Vault、AWS Secrets Manager、Doppler、GitHub Secrets 等。
• 在發(fā)布前妥善清理（Clean properly before publishing）使用如下工具：

a.TruffleHog

b.deepsecret

c.semgrep Secrets

d.BFG Repo-Cleaner

e.git filter-repo

我推薦：

1. 結(jié)合使用 deepsecrets 或 semgrep-secrets 與 truffleHog 或 gitleaks。它們基于上下文檢測(cè)秘密，而不僅僅是熵（entropy）或正則表達(dá)式。例如，passwd: hello 可能會(huì)被標(biāo)準(zhǔn)工具遺漏，但不會(huì)被 deepsecrets 遺漏。但你也應(yīng)該預(yù)料到會(huì)有誤報(bào)，因?yàn)樗赡鼙蛔鳛槭纠峒啊?/span>
2. 在 CI 流水線中自動(dòng)化掃描。

• 聯(lián)系 GitHub 支持進(jìn)行移除（Contact GitHub Support for Removals）如果你不小心推送了敏感數(shù)據(jù)，聯(lián)系支持部門，GitHub 可以從其后端清除對(duì)象，但這并非即時(shí)生效或有保證的。
• 如果秘密暴露了，就輪換它們（Rotate secrets if they get exposed）

作為最重要的一步，輪換秘密而不是試圖刪除它們。一旦秘密暴露，就假設(shè)它已泄露并進(jìn)行更改。不要心存僥幸！

譯者介紹

涂承燁，51CTO社區(qū)編輯，具有15年以上的開發(fā)、項(xiàng)目管理、咨詢?cè)O(shè)計(jì)等經(jīng)驗(yàn)，獲得系統(tǒng)架構(gòu)設(shè)計(jì)師、信息系統(tǒng)項(xiàng)目管理師、信息系統(tǒng)監(jiān)理師、PMP，CSPM-2等認(rèn)證。

原文標(biāo)題：Why GitHub Commits Aren’t as Private as You Think，作者：Vladimir Shelkovnikov