Выпуск распределенной системы управления исходными текстами Git 2.29
20 октября 2020 года
Доступен выпуск распределенной системы управления исходными текстами Git 2.29.0. Git является одной из самых популярных, надёжных и высокопроизводительных систем управления версиями, предоставляющей гибкие средства нелинейной разработки, базирующиеся на ответвлении и слиянии веток. Для обеспечения целостности истории и устойчивости к изменениям "задним числом" используются неявное хеширование всей предыдущей истории в каждом коммите, также возможно удостоверение цифровыми подписями разработчиков отдельных тегов и коммитов.
По сравнению с прошлым выпуском в новую версию принято 627 изменений, подготовленных при участии 89 разработчиков, из которых 24 впервые приняли участие в разработке. Основные новшества:
- Включена экспериментальная возможность использования алгоритма хэширования SHA-256 вместо скомпрометированного SHA-1 при записи объектов в репозиторий. Хэш формируется на основе содержимого каждого объекта в Git и является его уникальным идентификатором. Любое изменение данных или заголовков объекта приводит к изменению его идентификатора. Выявление возможности возникновения коллизий в алгоритме хэшировния теоретически допускает формирование двух разных наборов данных, имеющих один результирующий хэш. При активности в пять миллионов коммитов в секунду вероятность возникновения естественной коллизии оценивается в 50% за 7 млрд лет.
К сожалению алгоритм SHA-1 оказался не стойким к искусственному формированию коллизий, но совершение реальных атак по подмене объектов в Git через манипуляцию коллизиями SHA-1 маловероятно, так как для подмены отдельного объекта необходимо, чтобы подменяемый объект уже содержал шаблон коллизии, т.е. произвольный блок подменить не получится. Теоретически возможна лишь замена уже ранее добавленного атакующим блока, но она требует чтобы в изначально принятом в репозиторий вредоносном блоке присутствовал достаточно большой кусок бинарных данных, вызывающих коллизию, что при работе с кодом не останется незамеченным. Кроме того, каждый объект в Git содержит не только данные, но и служебный заголовок, содержимое которого не подконтрольно атакующему, но который участвует при вычислении проверочного хэша, что нарушает условия возникновения коллизии.
Так как каждая коллизия требует огромных ресурсов для вычисления, уже вычисленные шаблоны, приводящие к коллизиям, известны и ранее в git была добавлена проверка на попытки их использования в объектах. Теперь Git переходит на новый уровень защиты и намерен заменить алгоритм хэширования на более надёжный, что требует изменения формата объектов. Изначально планировалось использовать алгоритм SHA3-256, но в конечном счёте разработчики остановились на SHA2-256, так как SHA2 уже применяется в Git для цифровых подписей. Логика выбора в том, при использовании SHA-256 и SHA3-256 в коде Git, компрометация любого из них приведёт к проблемам с безопасностью, поэтому лучше зависеть от одного алгоритма, а не от двух. Кроме того, SHA-256 широко распространён и поддерживается во всех криптографических библиотеках, а также демонстрирует очень хорошую производительность.
В Git 2.29 реализована возможность включения нового формата при создании репозитория: $ git init --object-format=sha256 repo Initialized empty Git repository in /home/ttaylorr/repo/.git/ $ cd repo $ echo 'Hello, SHA-256!' >README.md $ git add README.md $ git commit -m "README.md: initial commit" [master (root-commit) 6e92961] README.md: initial commit 1 file changed, 1 insertion(+) create mode 100644 README.md $ git rev-parse HEAD 6e929619da9d82c78dd854dfe237c61cbad9e95148c1849b1f96ada5ee800810
На данном этапе можно лишь выбрать между SHA-1 и SHA-256, но одновременно в одном репозитории сочетать разные хэши пока невозможно. Также пока ни один Git-провайдер, включая GitHub, не поддерживает репозитории с хэшами SHA-256. В будущем планируют добавить возможности для обеспечения переносимости. В частности, будет добавлена возможность вычисления для записываемых объектов одновременно хэшей SHA-1 и SHA-256, с сохранением таблиц трансляции. Подобные таблицы трансляции позволят старым клиентам SHA-1 обращаться к репозиториям, использующим SHA-256, а также, после преобразования репозитория в SHA-256, дадут возможность продолжить обращения к коммитам по ссылкам с хэшами SHA-1.
- В команды "git fetch" и "git push" добавлена поддержка обратных спецификаций ссылок (refspec), расширающих правила отражения ссылок между ветками в локальном и внешнем репозиториях. Обратные спецификаций ссылок могут быть полезны в ситуациях, когда нужно не только выбрать, но и исключить некоторые ветки из сопоставления. Например, когда необходимо извлечь все ветки "refs/heads/*", кроме одной "refs/heads/ref-to-exclude", раньше требовалось создание больших списков, явно включающих каждую ветку, или использования скриптов вида: $ git ls-remote origin 'refs/heads/*' | grep -v ref-to-exclude | awk '{ print $2:$2 }' | xargs git fetch origin
В Git 2.29 появился оператор исключения "^". Выражения с данным оператором могут включать шаблоны, но охватывают только источник и не могут ссылаться на идентификаторы объектов. Начинающиеся с "^" спецификации ссылок будут исключены из сопоставления и рассматриваемый пример можно свести к команде: $ git fetch origin 'refs/heads/*:refs/heads/*' ^refs/heads/ref-to-exclude
Обратные спецификации ссылок также можно использовать в настройках: $ git config --add remote.origin.fetch ^refs/heads/foo
- В "git shortlog" появилась возможность группировки коммитов по содержимому дополнительных полей, таких как "Reviewed-by:" и "Coauthored-by:", а не только по автору или отправителю коммита ("git shortlog -c"). В Git 2.29 добавлена опция "--group", которая по умолчанию обеспечивает группировку автору ("--group=author"), а также поддерживает группировку по отправителю коммита ("--group=committer") и произвольным полям ("--group=trailer:поле"). Например, для вывода списка наиболее активной рецензирующих разработчиков можно указать:[[PRE] $ git shortlog -ns --group=trailer:reviewed-by v2.28.0.. | head -n5 40 Eric Sunshine 10 Taylor Blau 4 brian m. carlson 2 Elijah Newren 1 Jeff King[[/PRE]
Допускается указание нескольких выражений "--group" при запуске и использование опции "--format" для изменения формата вывода. Например, для учёта соавторов или помощников в списке:[[/PRE] $ git shortlog -ns --group=author --group=trailer:co-authored-by $ git shortlog --format="...helped %an on %as" --group=trailer:helped-by v2.28.0..v2.29.0[[/PRE]
- В "git for-each-ref" добавлены новые поля, которые можно указывать в опции "--format", помимо имени, типа и идентификатора объекта.Например, добавлены поля contents:size, subject:sanitize и модификатор :short для отображения коротких идентификаторов объектов. Также разрешено указание нескольких аргументов "--merged" и "--no-merged" для фильтрации ссылок.
- При возникновении конфликта в процессе выполнения операции "git merge" заголовок сообщения о коммите теперь помещается в скобки для более явного отделения данных из коммита от диагностических сообщений Git.
- Добавлена новая настройка "merge.renormalize", при установки которой операции сheck-out и check-in выполняются для каждой стадии трёхстороннего слияния.
- Возвращена отключённая в выпуске Git 2.27 вторая версия коммуникационного протокола Git, который используется при удалённом подключении клиента к Git-серверу. Ошибка, приводившая к проблемам со стабильностью, диагностирована и устранена.
- В команду "git bisect", используемую для выявления ревизии, в которой возникло регрессивное изменение, добавлена опция "--first-parent" для изменения отбора коммитов, проходящих между заведомо рабочей ревизией и ревизией в которой зафиксировано проявление проблемы. При указании "--first-parent" учитываются только коммиты в объединённой ветке, пропуская сам коммит на слияние.
- Повышена эффективность работы внутренней команды "git index-pack", применяемой при выполнении "git push" или "git fetch", за счёт распараллеливания операций упаковки индекса на многоядерных системах.
- Добавлена настройка "merge.suppressDest", управляющая добавлением фразы "into $dest" в сообщения "Merge $upstream into $dest", выдаваемые при слиянии веток (ранее, по умолчанию для основной ветки фраза "into $dest" не выводилась).
- Устранена уязвимость в бэкенде "contrib/mw-to-git" (не собирается по умолчанию), предназначенном для помещения и извлечения данных из MediaWiki. Проблема позволяет выполнить код при обращении экземпляру MediaWiki, находящимся под контролем злоумышленника.
Источники[править]
Любой участник может оформить статью: добавить иллюстрации, викифицировать, заполнить шаблоны и добавить категории.
Любой редактор может снять этот шаблон после оформления и проверки.
Комментарии[править]
Если вы хотите сообщить о проблеме в статье (например, фактическая ошибка и т. д.), пожалуйста, используйте обычную страницу обсуждения.
Комментарии на этой странице могут не соответствовать политике нейтральной точки зрения, однако, пожалуйста, придерживайтесь темы и попытайтесь избежать брани, оскорбительных или подстрекательных комментариев. Попробуйте написать такие комментарии, которые заставят задуматься, будут проницательными или спорными. Цивилизованная дискуссия и вежливый спор делают страницу комментариев дружелюбным местом. Пожалуйста, подумайте об этом.
Несколько советов по оформлению реплик:
- Новые темы начинайте, пожалуйста, снизу.
- Используйте символ звёздочки «*» в начале строки для начала новой темы. Далее пишите свой текст.
- Для ответа в начале строки укажите на одну звёздочку больше, чем в предыдущей реплике.
- Пожалуйста, подписывайте все свои сообщения, используя четыре тильды (~~~~). При предварительном просмотре и сохранении они будут автоматически заменены на ваше имя и дату.
Обращаем ваше внимание, что комментарии не предназначены для размещения ссылок на внешние ресурсы не по теме статьи, которые могут быть удалены или скрыты любым участником. Тем не менее, на странице комментариев вы можете сообщить о статьях в СМИ, которые ссылаются на эту заметку, а также о её обсуждении на сторонних ресурсах.
