访问源代码可以分析应用程序的安全性和安全性。但是，如果没有人真正查看代码，则问题将不会被发现，即使人们正在积极查看代码，通常也有很多内容要查看。幸运的是，GitHub 有一个活跃的安全团队，最近，他们揭露了一个特洛伊木马程序，该程序已被提交到多个 Git 仓库中，甚至躲过了仓库所有者。虽然我们无法控制其他人如何管理自己的仓库，但我们可以从他们的错误中吸取教训。为此，本文回顾了在向您自己的仓库添加文件时的一些最佳实践。
了解你的仓库
这可以说是安全 Git 仓库的零规则。作为项目维护者，无论您是自己启动的还是从其他人那里采用的，了解您自己仓库的内容都是您的工作。您可能没有记住代码库中每个文件的列表，但是您需要了解您正在管理的基本组件。如果在几十次合并后出现一个无关的文件，您将很容易发现它，因为您不知道它是做什么用的，并且您需要检查它以刷新您的记忆。当发生这种情况时，请查看该文件并确保您确切了解为什么它是必要的。
禁止二进制大对象
Git 旨在用于文本，无论是用纯文本编写的 C、Python 或 Java，还是 JSON、YAML、XML、Markdown、HTML 或类似的东西。Git 不是二进制文件的理想选择。
这是两者之间的区别
$ 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`�二进制文件中的数据无法以与纯文本相同的方式进行解析，因此如果二进制文件中的任何内容发生更改，则必须重写整个文件。一个版本和另一个版本之间唯一的区别就是所有内容，这会很快累积起来。
更糟糕的是，二进制数据无法由您（Git 仓库维护者）合理地审计。这违反了零规则：了解您的仓库中有什么。
除了常用的 POSIX 工具外，您还可以使用 git diff 检测二进制文件。当您尝试使用 --numstat 选项对二进制文件进行差异比较时，Git 会返回空结果
$ 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
如果您正在考虑将二进制大对象提交到您的仓库，请先停下来思考一下。如果是二进制文件，它是通过某种方式生成的。有没有充分的理由不在构建时生成它们，而是将它们提交到您的仓库？如果您决定提交二进制数据确实有意义，请确保在 README 文件或类似文件中标识二进制文件在哪里、为什么它们是二进制文件以及更新它们的协议是什么。更新必须谨慎执行，因为对于您提交到二进制大对象的每次更改，该大对象的存储空间实际上都会翻倍。
保持第三方库为第三方
第三方库也不例外。虽然开源的众多好处之一是您可以自由地重复使用和重新分发您没有编写的代码，但是有很多充分的理由不将第三方库放在您自己的仓库中。首先，您无法完全为第三方担保，除非您自己审查了其所有代码（以及未来的合并）。其次，当您将第三方库复制到您的 Git 仓库中时，它会将注意力从真正的上游源分散开来。对该库有信心的人在技术上仅对该库的主副本有信心，而不是对随机仓库中存在的副本有信心。如果您需要锁定到特定版本的库，请为开发人员提供您的项目所需的发布的合理 URL，或者使用 Git Submodule。
抵制盲目使用 git add
如果您的项目是编译型的，请抵制使用 git add .（其中 . 是当前目录或特定文件夹的路径）作为添加任何和所有新内容的简单方法的冲动。如果您不是手动编译项目，而是使用 IDE 为您管理项目，这一点尤其重要。当 IDE 管理您的项目时，可能很难跟踪已添加到您的仓库中的内容，因此重要的是仅添加您实际编写的内容，而不是项目文件夹中弹出的任何新对象。
如果您确实使用了 git add .，请在推送之前查看暂存区中的内容。如果您在执行 git status 时在项目文件夹中看到不熟悉的对象，请查明它来自哪里以及在您运行 make clean 或等效命令后它为什么仍然在您的项目目录中。这是一种罕见的构建工件，在编译期间不会重新生成，因此在提交之前请三思。
使用 Git ignore
为程序员构建的许多便利功能也非常嘈杂。任何项目（编程、艺术或其他）的典型项目目录都散布着隐藏文件、元数据和剩余工件。您可以尝试忽略这些对象，但是您的 git status 中的噪声越多，您就越有可能错过某些内容。
您可以通过维护一个良好的 gitignore 文件来为您 Git 过滤掉这些噪声。由于这是任何使用 Git 的人的常见要求，因此有一些入门级的 gitignore 文件可用。Github.com/github/gitignore 提供了几个专门构建的 gitignore 文件，您可以下载并将其放入您自己的项目中，并且 Gitlab.com 在几年前将 gitignore 模板集成到仓库创建工作流程中。使用这些来帮助您为您的项目构建合理的 gitignore 策略，并坚持下去。
审查合并请求
当您通过电子邮件收到合并请求、拉取请求或补丁文件时，不要仅仅测试它以确保它有效。您的工作是阅读进入您的代码库的新代码，并了解它是如何产生结果的。如果您不同意该实现，或者更糟糕的是，您不理解该实现，请向提交它的人发回消息并要求澄清。质疑旨在成为您仓库中永久组成部分的代码并不是社交失礼，但是不了解您合并到用户将要使用的代码中的内容，就违反了您与用户的社会契约。
负责任地使用 Git
开源中良好的软件安全性是一项社区努力。不要在您的仓库中鼓励不良的 Git 实践，也不要忽视您克隆的仓库中的安全威胁。Git 很强大，但它仍然只是一个计算机程序，因此请成为等式中的人，并确保每个人的安全。
3 条评论