Git 3.0's upcoming SHA-256 default will be a costly mistake

Переход Git 3.0 на SHA-256 в качестве алгоритма хеширования по умолчанию — это дорогостоящая ошибка, которая принесёт больше проблем, чем пользы. SHA-1, несмотря на теоретическую уязвимость к коллизиям, на практике никогда не приводил к реальным сбоям в репозиториях Git за два десятилетия использования. Вероятность случайной коллизии настолько мала (порядка 1,4 септиллиона файлов в одном проекте), что её можно пренебречь. Реальные атаки типа SHAttered требуют целенаправленных усилий и не угрожают обычным рабочим процессам.

Основной аргумент против перехода — колоссальная стоимость миграции: все существующие репозитории, инструменты, скрипты и интеграции, построенные вокруг SHA-1, потребуют обновления или полной переработки. Это вызовет глобальные сбои в CI/CD, инструментах анализа кода, системах резервного копирования и сторонних сервисах. Вместо радикальной смены алгоритма автор предлагает более разумное решение: добавить вторичную подпись на основе SHA-256 к существующим объектам Git, сохраняя SHA-1 как адресный ключ. Такой подход обеспечит криптографическую целостность без разрушения экосистемы, удовлетворит требования NIST и уберёт излишние нагрузки от механизмов обнаружения коллизий (sha1dc). В итоге, выгода от перехода на SHA-256 минимальна, а издержки — огромны и распространятся на весь мир разработки.

Комментарии (394)

Переход на SHA-256 в Git 3.0 технически реализуем с обратной совместимостью, но сталкивается с практическими проблемами совместимости подмодулей и инфраструктуры, а не с криптографической необоснованностью. SHA-1 не является теоретической уязвимостью — атака SHAttered 2017 года доказала практическую возможность коллизий. Git не был затронут, потому что никто не пытался подобрать префикс git-blob. Коллизии позволяют внедрять вредоносный код, если два репозитория имеют одинаковый хеш коммита, но разное содержимое в рабочей директории. Fossil SCM перешёл на SHA3-256 за 6 дней после SHAttered, сохранив старые хеши и не требуя перестройки репозиториев — миграция возможна без поломки ссылок. Git-документация подтверждает наличие двунаправленного отображения между SHA-1 и SHA-256, позволяющего ссылаться на объекты по старым хешам, но ограничивает смешанные репозитории и подмодули. Linus Torvalds в 2007 году заявлял, что SHA-1 в Git — это не функция безопасности, а средство проверки целостности, что ставит под сомнение необходимость перехода ради «безопасности». GitHub пока не поддерживает SHA-256 репозитории; автор статьи, возможно, фальсифицировал скриншот интерфейса. Выбор формата по первому коммиту — разумное решение. Подмодули в SHA-256 репозиториях могут ссылаться на SHA-1 подмодули — тесты на Git 2.47.3 подтверждают, что это работает без ошибок. Предлагается использовать git2/git3 как алиасы для выбора хеш-алгоритма при инициализации репозитория, чтобы избежать случайного перехода на SHA-256 в старых средах. Компании и госорганизации, запрещающие SHA-1 по политике безопасности, вынуждают Git перейти на SHA-256 не из-за криптографических угроз, а из-за требований сертификации. Утверждение, что SHA-256 — это «новый IPv6», опровергается: переход не требует полной замены инфраструктуры, а использует маппинг хешей, что делает его менее разрушительным. Хеш-коллизии в Git не являются проблемой для большинства пользователей, так как они используют сокращённые хеши (7–10 символов), а не полные, и не полагаются на них как на криптографические доказательства. Атака «Shambles» — это chosen-prefix collision, ближе к second-preimage, чем к обычной коллизии, и поэтому представляет более серьёзную угрозу, чем утверждает автор статьи. Предлагается хранить оба хеша (SHA-1 и SHA-256) в репозитории после миграции, чтобы старые ссылки не ломались, как это делает Fossil SCM. Математическая вероятность случайной коллизии SHA-1 в одном проекте — 1.4 септиллиона файлов, но это не учитывает целенаправленные атаки, которые требуют лишь тысяч вычислений. Переход на SHA-256 — это не только вопрос безопасности, но и инфраструктурной устойчивости: Git должен быть готов к будущим сменам хеш-функций, а текущий подход не обеспечивает криптографической гибкости.