6 лучших практик для безопасного управления Git-репозиториями

Автор оригинала: Seth Kenlon
  • Перевод
Избегайте захламления репозиториев и других действий, которые усложняют управление кодовой базой. Вместо этого используйте лучшие практики, которые помогут упростить работу.



Изучение исходников в репозитории позволяет оценить уровень безопасности приложений. Но если никто не смотрит на код, проблемы будут только расти. К счастью, у GitHub есть свои специалисты по безопасности, которые недавно обнаружили трояна в нескольких репозиториях Git. Его почему-то не заметили сами владельцы этих репозиториев. Хотя мы не можем диктовать другим людям, как управлять своими собственными хранилищами, мы можем учиться на их ошибках. В этой статье мы рассмотрим полезные приёмы работы с репозиториями.

Изучите свой репозиторий



Возможно, это самая важная рекомендация. Независимо от того, самостоятельно ли вы создали репозиторий или вам его передали, важно знать содержимое вашего хранилища. Как минимум, нужно знать основные компоненты кодовой базы, которой вы управляете. Если после нескольких десятков слияний появится случайный файл, вы сможете легко его обнаружить, потому что он вызовет у вас вопросы. Далее вы захотите проверить его, чтобы разобраться, и уже после этого решите его судьбу.

Старайтесь не добавлять бинарники



Git изначально заточен под текстовые файлы, будь то код на C, Python или Java, или JSON, YAML, XML, Markdown, HTML и так далее:

$ 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 «не любит» бинарные файлы:

$ 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:0

Данные в двоичном файле не могут быть проанализированы таким же образом, как обычный текст, поэтому, если что-то изменится в двоичном файле, он должен быть перезаписан полностью.

Что ещё хуже, вы сами не можете проверить (прочитать и проанализировать) двоичные данные.
В дополнение к обычным инструментам POSIX вы можете найти двоичные файлы, используя git diff. Когда вы попытаетесь запустить команду 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, это смещает фокус с основного проекта.

Для управления внешними зависимостями используйте Git Submodule.

Не используйте git add «вслепую»



Если ваш проект успешно скомпилирован, не поддавайтесь желанию использовать команду git add. (где «.» — это текущий каталог например). Это особенно важно, если вы не компилируете свой проект вручную, а используете IDE для управления своим проектом. Может быть чрезвычайно сложно отследить, что было добавлено в ваш репозиторий, когда вашим проектом управляет IDE. Поэтому важно добавлять только то, что вы сами создали и подготовили для добавления, а не какой-либо новый объект, который загадочным образом появился в папке вашего проекта.

Так что, прежде чем запускать git add, просмотрите, что будет добавлено в репозиторий. Если вы видите незнакомый объект, выясните, откуда он и почему он всё ещё находится в каталоге вашего проекта после выполнения команды make clean (или эквивалентной команды).

Используйте Git ignore



Типичный каталог любого проекта содержит множество скрытых файлов, метаданных и ненужных артефактов. Вам лучше игнорировать эти объекты: чем больше их будет, тем больше вероятность того, что вам будет мешать этот «мусор» и вы пропустите что-то важное или опасное.

Файл .gitignore даёт возможность отфильтровать лишнее. Github.com/github/gitignore предлагает несколько специально созданных шаблонов gitignore, которые вы можете загрузить и разместить в своём проекте. Gitlab.com, например, предлагал такие шаблоны ещё несколько лет назад.

Модерируйте изменения кодовой базы



Когда вы получаете запрос на слияние или pull-запрос, либо вам присылают патч по электронной почте, вам стоит убедиться, что там всё нормально. Ваша задача — изучить новый код, поступающий в вашу кодовую базу, и понять, что он делает. Если вы не согласны с его реализацией или, что ещё хуже, не понимаете эту реализацию, напишите отправителю сообщение и попросите разъяснений. Нет ничего зазорного в том, чтобы изучать новый код, который претендует на место в вашем проекте. Более того, вы делаете это на благо ваших пользователей: они в этом случае будут чётко понимать, какие изменения вы принимаете и почему.

Возьмите на себя ответственность


Обеспечение безопасности программного обеспечения с открытым исходным кодом — это работа сообщества. Изучайте кодовую базу, не поощряйте беспорядок и не игнорируйте потенциальные угрозы безопасности в клонированных вами репозиториях. Git — мощный инструмент, но это всего лишь компьютерная программа, так что ответственность за управление репозиториями в конечном счёте лежит на вас.



На правах рекламы


Эпичные серверы — это виртуальные серверы на Linux или Windows с мощными процессорами семейства AMD EPYC и очень быстрыми NVMe дисками Intel. Расходятся, как горячие пирожки!

VDSina.ru — хостинг серверов
Серверы в Москве и Амстердаме

Комментарии 14

    +1

    Забавно, что в качестве примера к "старайтесь не добавлять бинарники" выбран png.

      0
      Старайтесь не добавлять бинарники

      Для решения этого вопроса уже давно существует Git LFS

        +8
        Кудаж без таких советов
          0
          Обновления должны выполняться экономно, поскольку при каждом изменении, которое вы вносите в двоичный объект, пространство для его хранения удваивается.

          Насколько я помню, это не так. Если в бинарнике изменилась небольшая часть, то в паках git не будет сохранять обе версии целиком, будет храниться только diff. А без паков дублируются не только бинарные объекты, но и текстовые тоже.


          Хранить в репозитории бинарники — плохая идея, но не по соображениям занимаемого места.

            0
            > Хранить в репозитории бинарники — плохая идея, но не по соображениям занимаемого места.

            Отчасти и по соображениям занимаемого места (скорее — времени клонирования, место сейчас дешевое), это зависит от типа бинарника — например, если в картинке поменять один пиксель, новый PNG файл может иметь очень мало общего со старым (из-за встроенной компрессии), и никакой diff не поможет. Но, полностью согласен, место — далеко не самое важное.
            +2
            пафоса то в названии
              +3
              Для управления внешними зависимостями используйте Git Submodule.

              Довольно сомнительный совет, который сильно усложнит работу с репо для всех.


              В качестве альтернативы я бы порекомендовал https://github.com/ingydotnet/git-subrepo — тоже не идеал, но проблем с ним намного меньше.

                +1
                Данные в двоичном файле не могут быть проанализированы таким же образом, как обычный текст, поэтому, если что-то изменится в двоичном файле, он должен быть перезаписан полностью.

                В гите тестовые файлы тоже перезаписываются полностью.

                Честно говоря, статья выглядит перепечаткой человека, который сам с гитом мало работал.
                  0

                  Нужно ли в репозиторий добавлять gitignor?

                    0
                    Скорее да, к тому же есть готовые шаблоны для разных языков. А вот надо ли добавлять в гитигнор служебный каталог IDE — это уже весьма дискусионный вопрос
                      0

                      Конечно же, надо. Просто не в .gitignore конкретного репо, а в ~/.gitignore, путь к которому надо задать через git config --global core.excludesFile.

                        0

                        Одно другому не мешает.
                        Глобальный gitignore делается самим разработчиком и зависит от ide и других личных привычек.
                        Проектный gitignore зависит от структуры проекта и его специфики.

                      0
                      Я бы необходимость использовать .gitignore вынес на первое место.

                      И самое главное о чем автор не упомянул — это всякие секреты (пароли и другие реквизиты доступа). Их нужно было отдельно упомянуть и четко прописать работу сними (и да — все это должны быть добавлено в .gitignore)
                      0

                      Я бы сказал так: «для управления внешними зависимостями используйте пакетные менеджеры, и только в крайнем случае — git submodules».

                      Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                      Самое читаемое