Git 3.0 — это больше, чем просто номер версии
Git 3.0 готов стать первым мажорным релизом с критическими изменениями для системы контроля версий с момента выхода Git 2.0 в 2014 году. Хотя официальная дата релиза еще не установлена, запланированы два значительных изменения, которые повлияют на разработчиков и инфраструктуру: Rust станет обязательной зависимостью при сборке, а SHA-256 станет алгоритмом хеширования по умолчанию для новых репозиториев.
Переход на Rust направлен на повышение безопасности памяти, что позволит устранить распространенный источник уязвимостей в кодовой базе Git на C. Хотя компоненты на Rust были включены по умолчанию в последних релизах Git 2.x, в Git 3.0 будет удалена возможность их отключения во время компиляции, что сделает Rust обязательным условием для сборки программного обеспечения.
Одновременно проект планирует переход с SHA-1 на SHA-256 в качестве хеша по умолчанию для новых репозиториев. Это изменение увеличит длину хешей коммитов с 40 до 64 символов, что повлияет на существующие инструменты, скрипты и конвейеры непрерывной интеграции (CI), которые ожидают более короткий формат.
Критически важно различать анонсированные планы и выпущенное программное обеспечение. Rust был опциональным компонентом по умолчанию в версиях Git 2.x, но Git 3.0 еще не выпущен. Существующие репозитории не будут автоматически конвертироваться в SHA-256; изменение затронет только вновь инициализированные репозитории.
Требование Rust имеет свою цену для платформ
Git 3.0 сделает Rust toolchain обязательным для компиляции — этот шаг продиктован проблемами безопасности памяти. Значительная часть уязвимостей Git исторически была связана с ошибками памяти в кодовой базе на C, что побудило основную команду разработчиков интегрировать компоненты на Rust.
Это требование создает проблемы совместимости платформ. Компилятор Rust и связанный с ним инструментарий поддерживают не все устаревшие или проприетарные Unix-платформы, на которых Git в настоящее время успешно собирается. Хотя Rust был опциональным компонентом по умолчанию в последних релизах Git 2.x, в Git 3.0 эта гибкость будет устранена.
Чтобы смягчить немедленные сбои, финальный релиз Git 2.x получит расширенную долгосрочную поддержку (LTS). Эта мера призвана дать командам на неподдерживаемых платформах дополнительное время для разработки долгосрочной стратегии своей инфраструктуры Git, поскольку дальнейшие обновления потребуют совместимой среды сборки.
Почему 64-символьные хеши могут вызвать проблемы в CI
Git 3.0 увеличит идентификаторы объектов с 40 до 64 шестнадцатеричных символов, перейдя с хешей SHA-1 (160 бит) на SHA-256 (256 бит). Это изменение, повышая криптографическую стойкость к коллизиям, создает существенный технический долг совместимости для существующих рабочих процессов Git.
Сотни тысяч внутренних скриптов, регулярных выражений и кешей CI в настоящее время предполагают длину хеша в 40 символов. Обновление этих систем потребует значительных инженерных усилий в организациях и затронет:
- CI/CD конвейеры
- Git хуки
- Сторонние инструменты
- Внутренние механизмы кеширования
Совместимость репозиториев представляет собой еще одну проблему. Репозитории SHA-256 не могут беспрепятственно интегрировать репозитории SHA-1 в качестве подмодулей без внедрения специальных механизмов связки. Хостинговые платформы также должны обновить свою инфраструктуру для поддержки нового формата хеширования, иначе пользователи столкнутся с ограниченной функциональностью.
Сооснователь GitHub Скотт Чакон охарактеризовал эту миграцию как «глобальный кошмар», утверждая, что практические преимущества для безопасности минимальны по сравнению с издержками для всей экосистемы. Он ссылается на исходное утверждение Линуса Торвальдса от 2005 года о том, что безопасность Git фундаментально опирается на распределенное доверие, а не только на устойчивые к коллизиям хеши. Подробнее о предстоящих изменениях см. в документации BreakingChanges - Git.
Нравится статья? Получайте такие каждое утро на почту.
одно письмо в день · отписка в два клика · без сторонних трекеров
Дискуссия о безопасности — и что нужно протестировать сейчас
Переход на SHA-256 вызвал споры о соотношении преимуществ для безопасности и затрат на миграцию. Сооснователь GitHub Скотт Чакон утверждает, что практический выигрыш в безопасности минимален, аргументируя это тем, что модель безопасности Git, описанная Линусом Торвальдсом в 2005 году, в первую очередь опирается на распределенное доверие и контроль доступа. Чакон предполагает, что компрометация учетных данных репозитория или социальная инженерия в отношении мейнтейнера представляют собой менее затратный и более вероятный вектор атаки, чем криптографическая коллизия.
Мейнтейнеры возражают, что известные уязвимости SHA-1, включая продемонстрированные атаки на основе коллизий, требуют подготовки до того, как кризис заставит решать проблему. Хотя более сильные хеши не решают проблему скомпрометированных учетных данных или социальной инженерии, криптографическая целостность остается отдельным и критически важным компонентом доверия к репозиторию. Инженеры Git из Google признают наличие проблем, но предупреждают, что коллизии SHA-1 станут проще, и если откладывать изменения, индустрия окажется в сложной ситуации.
Разработчики могут протестировать совместимость с SHA-256 уже сегодня, используя команду git init --object-format=sha256. Эта команда инициализирует новые репозитории в формате SHA-256. Существующие репозитории не будут автоматически конвертированы и сохранят свой формат объектов SHA-1.
Тестирование должно быть сосредоточено на:
- Конвейерах непрерывной интеграции (CI)
- Скриптах автоматизации
- Обработке подмодулей (submodules)
- Поддержке хост-системой новой длины хеша
Эти проактивные проверки помогут выявить потенциальные точки сбоя во всей цепочке инструментов разработки.
Часто задаваемые вопросы
Каковы основные запланированные изменения в Git 3.0?
Ожидается, что для сборки Git 3.0 потребуется Rust, а SHA-256 станет форматом хеширования по умолчанию для вновь инициализируемых репозиториев. Официальной даты релиза пока нет.
Преобразует ли Git 3.0 мой существующий репозиторий в SHA-256?
Нет. Существующие репозитории сохраняют свой текущий формат объектов; запланированное использование SHA-256 по умолчанию применяется только к вновь инициализируемым репозиториям.
Как я могу попробовать использовать Git-репозиторий с SHA-256 прямо сейчас?
Запустите git init --object-format=sha256 для инициализации репозитория с использованием SHA-256, с учетом ограничений совместимости ваших инструментов и платформы хостинга.
Почему Rust становится требованием для сборки Git?
Заявленная цель — снижение рисков, связанных с безопасностью памяти в Git. Компромисс заключается в том, что некоторые платформы без поддержки инструментария Rust могут оказаться не в состоянии собрать Git 3.0.