GitHub выполнил ранее анонсированное отключение хеш-функции SHA-1 в HTTPS-соединениях. С 15 сентября 2026 года платформа перестала принимать SHA-1-сертификаты для github.com, а также для партнёрских CDN, GitHub Enterprise Cloud и GitHub Enterprise Cloud with Data Residency. GitHub Enterprise Server (self-hosted) не затронут.
Это плановое изменение, о котором GitHub предупреждал заранее. Для большинства современных пользователей переход будет незаметным, но legacy-инструменты, написанные до 2015–2017 годов, могут потребовать обновления.
Что именно изменилось
С 15 сентября 2026 года GitHub отклоняет HTTPS-соединения, использующие сертификаты, подписанные с SHA-1. Это касается:
- прямых обращений к github.com;
- запросов через партнёрские CDN (Akamai, Fastly и другие);
- всех облачных версий GitHub Enterprise, кроме self-hosted (GHES).
GitHub Enterprise Server не затронут, так как администраторы инстанций сами управляют сертификатами. Однако рекомендуется вручную проверить настройки TLS на своих серверах.
Почему это важно для разработчиков и AI-инфраструктуры
SHA-1 считается криптографически сломанным с 2017 года, когда команда Google и Centrum Wiskunde & Informatica продемонстрировала коллизию (SHAttered). С тех пор браузеры, операционные системы и крупные платформы постепенно отказываются от SHA-1. GitHub — один из последних крупных хостингов, завершивших этот процесс.
Для AI-инфраструктуры это имеет прямое значение:
- CI/CD пайплайны: старые раннеры, написанные на Python 2.7 или использующие устаревшие библиотеки `requests` (< 2.25.0), могут не поддерживать SHA-2.
- Git-клиенты: версии Git до 1.8.5 (2013 год) не поддерживают SHA-256 в подписях. Если ваш CI/CD использует контейнеры с ультра-лёгкими дистрибутивами (Alpine Linux старше 3.8), проверьте версию Git.
- Самодельные боты и скрипты: многие AI-агенты, парсящие GitHub API или выкачивающие модели, используют `curl` или `wget` из образов. Убедитесь, что они собраны с OpenSSL 1.1.1+ или LibreSSL 2.7+.
Как проверить свою инфраструктуру
Самый простой способ — выполнить тестовый запрос к GitHub API с явным указанием SHA-1:
bash
curl -I —tlsv1.2 —ciphers ‘SHA1’ https://api.github.com/
Если команда возвращает ошибку `SSL_ERROR_NO_CYPHER_OVERLAP` или `certificate verify failed`, ваш клиент больше не сможет работать с GitHub по HTTPS.
Для проверки Git-клиента:
bash
git ls-remote https://github.com/username/repo.git
Если команда завершается ошибкой SSL, обновляйте Git.
Кого это не затронет
- Пользователи современного Git (>= 2.0) на актуальных ОС (Ubuntu 20.04+, macOS 11+, Windows 10+).
- Все, кто использует SSH вместо HTTPS (ключи SSH не зависят от SHA-1 в TLS).
- Владельцы GitHub Enterprise Server — они управляют сертификатами самостоятельно.
Практический чек-лист для AI-разработчика
Проверьте образы Docker, используемые в CI/CD (GitHub Actions, GitLab CI, Jenkins). Замените устаревшие образы на `ubuntu:22.04`, `python:3.11-slim` или `node:20`.
2. Если вы используете GitHub Actions, убедитесь, что раннеры обновлены до последней версии (GitHub автоматически обновляет хостинг-раннеры, но self-hosted — ваша ответственность).
3. Проверьте скрипты на Python: в `pip freeze` версия `requests` должна быть >= 2.25.0, `urllib3` >= 1.26.0.
4. Для Rust-проектов: убедитесь, что `rustls` или `native-tls` собраны с поддержкой SHA-256 (все актуальные версии).
5. Если вы используете GitHub Enterprise Cloud with Data Residency (например, в ЕС или Австралии), изменения уже вступили в силу — проверьте логи на предмет ошибок SSL.
Что дальше
GitHub не анонсировал дальнейших немедленных изменений, но отключение SHA-1 — это часть долгосрочного плана по модернизации криптографии. Следующим шагом, вероятно, станет обязательная поддержка TLS 1.3 и отказ от TLS 1.0/1.1 (хотя они уже давно не рекомендуются).
Для сообщества AI-разработчиков это напоминание: инфраструктурные изменения в платформах-донорах (GitHub, Hugging Face, GitLab) требуют регулярного аудита ваших пайплайнов. Один устаревший образ Docker может остановить развёртывание модели.
Если вы используете GitHub Enterprise Server и хотите сохранить SHA-1 (например, для совместимости со старым корпоративным ПО), это возможно — GHES не затронут. Но настоятельно рекомендуется как можно скорее перейти на SHA-256.