После ноябрьского выпуска исправлений Git стоит проверить не только терминал на рабочем ноутбуке. Нередко разработчик обновляет одну установку, а редактор, сборочная машина или контейнер продолжают пользоваться другой. Ниже — практический порядок проверки: от списка установок до подтверждения результата.

Что произошло 10 ноября

Проект Git выпустил исправления шести уязвимостей. Они затрагивают рекурсивное клонирование, обработку ссылок на ветви, слияния, двоичные патчи и импорт. Возможные последствия различаются: от аварийного завершения до записи не в те файлы и выполнения чужого кода при работе со специально подготовленным репозиторием.

Исправления вошли в Git 2.56.1. Для поддерживаемых более ранних веток указаны версии 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 и 2.50.2. Рекомендация сопровождающих касается также приложений, поставляющих собственную копию Git. Наличие проблемы само по себе не означает, что конкретный компьютер уже был взломан.

Шаг первый: составить карту установок

Начните с обычного терминала и выполните git --version. Эта команда выводит версию запущенной программы. Сохраните результат вместе с названием компьютера и способом установки. Затем повторите проверку в средах, где действительно выполняется работа: во встроенном терминале редактора, в Linux-окружении, на сборочном агенте и внутри используемого контейнера.

Для каждой среды заведите короткую запись: кто отвечает за обновление, какой пакет или приложение предоставляет Git и как будет проверен результат. Такой список полезнее единственной строки «обновлено» в командном чате: он показывает оставшиеся пробелы и позволяет передать работу другому человеку.

Шаг второй: обновить через привычный канал

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

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

Шаг третий: проверить то, что реально запускается

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

Контейнеры и готовые образы внесите в самостоятельный пункт плана: зафиксируйте пересборку и запуск обновлённого варианта. Не проверяйте исправление сомнительными демонстрационными репозиториями из обсуждений. Для приёмки достаточно подтверждённого пакета и обычного тестового проекта, которому вы доверяете.

Когда работу можно считать завершённой

Наш критерий простой: у каждой рабочей среды есть ответственный, подтверждение исправления и повторная проверка используемой программы. Сохраните эту таблицу как шаблон следующего обновления. Тогда очередное уведомление о безопасности станет короткой процедурой обслуживания, а не поиском давно забытой копии инструмента.

Обложка — оригинальная сгенерированная концептуальная иллюстрация, не снимок интерфейса.