有權(quán)訪問(wèn)源代碼使對(duì)安全性的分析以及應(yīng)用程序的安全成為可能。但是，如果沒(méi)有人真正看過(guò)代碼，問(wèn)題就不會(huì)被發(fā)現(xiàn)，即使人們主動(dòng)地看代碼，通常也要看很多東西。幸運(yùn)的是，GitHub 擁有一個(gè)活躍的安全團(tuán)隊(duì)，最近，他們 發(fā)現(xiàn)了已提交到多個(gè) Git 倉(cāng)庫(kù)中的特洛伊木馬病毒，甚至倉(cāng)庫(kù)的所有者也偷偷溜走了。盡管我們無(wú)法控制其他人如何管理自己的倉(cāng)庫(kù)，但我們可以從他們的錯(cuò)誤中吸取教訓(xùn)。為此，本文回顧了將文件添加到自己的倉(cāng)庫(kù)中的一些最佳實(shí)踐。

[[387426]]

了解你的倉(cāng)庫(kù)

Git 倉(cāng)庫(kù)終端這對(duì)于安全的 Git 倉(cāng)庫(kù)來(lái)可以說(shuō)是頭號(hào)規(guī)則。作為項(xiàng)目維護(hù)者，無(wú)論是你自己創(chuàng)建的還是采用別人的，你的工作是了解自己倉(cāng)庫(kù)中的內(nèi)容。你可能無(wú)法記住代碼庫(kù)中每一個(gè)文件，但是你需要了解你所管理的內(nèi)容的基本組成部分。如果在幾十個(gè)合并后出現(xiàn)一個(gè)游離的文件，你會(huì)很容易地發(fā)現(xiàn)它，因?yàn)槟悴恢浪挠猛?，你需要檢查它來(lái)刷新你的記憶。發(fā)生這種情況時(shí)，請(qǐng)查看該文件，并確保準(zhǔn)確了解為什么它是必要的。

禁止二進(jìn)制大文件

終端中 Git 的二進(jìn)制檢查命令

Git 是為文本而生的，無(wú)論是用純文本編寫(xiě)的 C 或 Python 還是 Java 文本，亦或是 JSON、YAML、XML、Markdown、HTML 或類似的文本。Git 對(duì)于二進(jìn)制文件不是很理想。

兩者之間的區(qū)別是：

$ cat hello.txt 
This is plain text. 
It's readable by humans and machines alike. 
Git knows how to version this. 
$ git diff hello.txt 
diff --git a/hello.txt b/hello.txt 
index f227cc3..0d85b44 100644 
--- a/hello.txt 
+++ b/hello.txt 
@@ -1,2 +1,3 @@ 
 This is plain text. 
+It's readable by humans and machines alike. 
 Git knows how to version this. 

和

$ git diff pixel.png 
diff --git a/pixel.png b/pixel.png 
index 563235a..7aab7bc 100644 
Binary files a/pixel.png and b/pixel.png differ 
$ cat pixel.png 
�PNG 
▒ 
IHDR7n�$gAMA�� 
              �abKGD݊�tIME� 
                          -2R�� 
IDA�c`�!�3%tEXtdate:create2020-06-11T11:45:04+12:00��r.%tEXtdate:modify2020-06-11T11:45:04+12:00��ʒIEND�B`� 

二進(jìn)制文件中的數(shù)據(jù)不能像純文本一樣被解析，因此，如果二進(jìn)制文件發(fā)生任何更改，則必須重寫(xiě)整個(gè)內(nèi)容。一個(gè)版本與另一個(gè)版本之間唯一的區(qū)別就是全部不同，這會(huì)快速增加倉(cāng)庫(kù)大小。

更糟糕的是，Git 倉(cāng)庫(kù)維護(hù)者無(wú)法合理地審計(jì)二進(jìn)制數(shù)據(jù)。這違反了頭號(hào)規(guī)則：應(yīng)該對(duì)倉(cāng)庫(kù)的內(nèi)容了如指掌。

除了常用的 POSIX 工具之外，你還可以使用 git diff 檢測(cè)二進(jìn)制文件。當(dāng)你嘗試使用 --numstat 選項(xiàng)來(lái)比較二進(jìn)制文件時(shí)，Git 返回空結(jié)果：

$ git diff --numstat /dev/null pixel.png | tee 
-     -   /dev/null => pixel.png 
$ git diff --numstat /dev/null file.txt | tee 
5788  0   /dev/null => list.txt 

如果你正在考慮將二進(jìn)制大文件(BLOB)提交到倉(cāng)庫(kù)，請(qǐng)停下來(lái)先思考一下。如果它是二進(jìn)制文件，那它是由什么生成的。是否有充分的理由不在構(gòu)建時(shí)生成它們，而是將它們提交到倉(cāng)庫(kù)?如果你認(rèn)為提交二進(jìn)制數(shù)據(jù)是有意義的，請(qǐng)確保在 README 文件或類似文件中指明二進(jìn)制文件的位置、為什么是二進(jìn)制文件的原因以及更新它們的協(xié)議是什么。必須謹(jǐn)慎對(duì)其更新，因?yàn)槟忝刻峤灰粋€(gè)二進(jìn)制大文件的變化，它的存儲(chǔ)空間實(shí)際上都會(huì)加倍。

讓第三方庫(kù)留在第三方

第三方庫(kù)也不例外。盡管它是開(kāi)源的眾多優(yōu)點(diǎn)之一，你可以不受限制地重用和重新分發(fā)不是你編寫(xiě)的代碼，但是有很多充分的理由不把第三方庫(kù)存儲(chǔ)在你自己的倉(cāng)庫(kù)中。首先，除非你自己檢查了所有代碼(以及將來(lái)的合并)，否則你不能為第三方完全擔(dān)保。其次，當(dāng)你將第三方庫(kù)復(fù)制到你的 Git 倉(cāng)庫(kù)中時(shí)，會(huì)將焦點(diǎn)從真正的上游源代碼中分離出來(lái)。從技術(shù)上講，對(duì)庫(kù)有信心的人只對(duì)該庫(kù)的主副本有把握，而不是對(duì)隨機(jī)倉(cāng)庫(kù)的副本有把握。如果你需要鎖定特定版本的庫(kù)，請(qǐng)給開(kāi)發(fā)者提供一個(gè)合理的項(xiàng)目所需的發(fā)布 URL，或者使用 Git 子模塊。

抵制盲目的 git add

Git 手動(dòng)添加命令終端中

如果你的項(xiàng)目已編譯，請(qǐng)抵制住使用 git add . 的沖動(dòng)(其中 . 是當(dāng)前目錄或特定文件夾的路徑)，因?yàn)檫@是一種添加任何新東西的簡(jiǎn)單方法。如果你不是手動(dòng)編譯項(xiàng)目，而是使用 IDE 為你管理項(xiàng)目，這一點(diǎn)尤其重要。用 IDE 管理項(xiàng)目時(shí)，跟蹤添加到倉(cāng)庫(kù)中的內(nèi)容會(huì)非常困難，因此僅添加你實(shí)際編寫(xiě)的內(nèi)容非常重要，而不是添加項(xiàng)目文件夾中出現(xiàn)的任何新對(duì)象。

如果你使用了 git add .，請(qǐng)?jiān)谕扑椭皺z查暫存區(qū)里的內(nèi)容。如果在運(yùn)行 make clean 或等效命令后，執(zhí)行 git status 時(shí)在項(xiàng)目文件夾中看到一個(gè)陌生的對(duì)象，請(qǐng)找出它的來(lái)源，以及為什么仍然在項(xiàng)目的目錄中。這是一種罕見(jiàn)的構(gòu)建工件，不會(huì)在編譯期間重新生成，因此在提交前請(qǐng)三思。

使用 Git ignore

終端中的命令

許多為程序員打造的便利也非常雜亂。任何項(xiàng)目的典型項(xiàng)目目錄，無(wú)論是編程的，還是藝術(shù)的或其他的，到處都是隱藏的文件、元數(shù)據(jù)和遺留的工件。你可以嘗試忽略這些對(duì)象，但是 git status 中的提示越多，你錯(cuò)過(guò)某件事的可能性就越大。

你可以通過(guò)維護(hù)一個(gè)良好的 gitignore 文件來(lái)為你過(guò)濾掉這種噪音。因?yàn)檫@是使用 Git 的用戶的共同要求，所以有一些入門級(jí)的 gitignore 文件。Github.com/github/gitignore 提供了幾個(gè)專門創(chuàng)建的 gitignore 文件，你可以下載這些文件并將其放置到自己的項(xiàng)目中，Gitlab.com 在幾年前就將gitignore 模板集成到了倉(cāng)庫(kù)創(chuàng)建工作流程中。使用這些模板來(lái)幫助你為項(xiàng)目創(chuàng)建適合的 gitignore 策略并遵守它。

查看合并請(qǐng)求

Git 合并請(qǐng)求

當(dāng)你通過(guò)電子郵件收到一個(gè)合并/拉取請(qǐng)求或補(bǔ)丁文件時(shí)，不要只是為了確保它能正常工作而進(jìn)行測(cè)試。你的工作是閱讀進(jìn)入代碼庫(kù)的新代碼，并了解其是如何產(chǎn)生結(jié)果的。如果你不同意這個(gè)實(shí)現(xiàn)，或者更糟的是，你不理解這個(gè)實(shí)現(xiàn)，請(qǐng)向提交該實(shí)現(xiàn)的人發(fā)送消息，并要求其進(jìn)行說(shuō)明。質(zhì)疑那些希望成為版本庫(kù)永久成員的代碼并不是一種社交失誤，但如果你不知道你把什么合并到用戶使用的代碼中，那就是違反了你和用戶之間的社交契約。

Git 責(zé)任

社區(qū)致力于開(kāi)源軟件良好的安全性。不要鼓勵(lì)你的倉(cāng)庫(kù)中不良的 Git 實(shí)踐，也不要忽視你克隆的倉(cāng)庫(kù)中的安全威脅。Git 功能強(qiáng)大，但它仍然只是一個(gè)計(jì)算機(jī)程序，因此要以人為本，確保每個(gè)人的安全。