Hacker News Digest

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

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

Переход на 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 должен быть готов к будущим сменам хеш-функций, а текущий подход не обеспечивает криптографической гибкости.

Pirate Face — децентрализованная сеть для хранения открытых ИИ-моделей в виде торрентов, чтобы они выжили даже после удаления с Hugging Face. Каждая модель копируется с проверкой SHA-256, гарантируя, что скачанные веса идентичны оригиналу. Даже если Hugging Face удалит модель, сеть пиров продолжает её поддерживать благодаря встроенным web-seed — HTTPS-ссылкам, которые работают как резервный источник до тех пор, пока не появятся пиры. Никакой централизованный хост не может её отключить.

Система совместима с существующими инструментами: достаточно изменить переменную HF_ENDPOINT, и все пайплайны начнут брать модели из сети Pirate Face без изменений в коде. Для использования не нужна регистрация — можно скачивать и раздавать без аккаунта. Аккаунты позволяют закрепить имя, подтвердить авторство через Hugging Face (для защиты от подделок) и получать будущие бонусы: бесплатные вычислительные ресурсы и эксклюзивные модели. Пока нельзя публиковать модели напрямую — они должны быть сначала загружены на Hugging Face. Баллы за участие (создание, раздача, рефералы) не являются валютой, но открывают доступ к будущим льготам.

Торрент-распространение моделей ИИ — жизненно важный механизм устойчивости против цензуры и централизованных сбоев. Оно устраняет единую точку отказа, как у Hugging Face, и делает невозможным полное уничтожение открытых весов, подобно фильмам в интернете. Однако имя «Pirate Face» создаёт негативный контекст, отпугивая участников, несмотря на легальность моделей; название должно подчёркивать устойчивость, а не незаконность. Сложности с созданием торрентов и отсутствие автоматизации снижают практическую эффективность: требуется ручная настройка для точного совпадения с файлами на Hugging Face. Web-seed позволяет резервировать HTTPS-ссылки, обеспечивая доступность даже при отсутствии пиров. Академические архивы вроде AcademicTorrents могут быть альтернативой, если поддерживают Hugging Face как бэкап. Критики считают распространение «abliterated» весов устаревшим: ортогонализация активаций на лету эффективнее и точнее переквантования. Квантованные модели (например, DeepSeek V4, Kimi K2.5) не должны переквантоваться после модификации — это ухудшает точность; лучше сохранять исходные веса и применять коррекции на уровне активаций. Централизованные платформы уязвимы для государственного давления; распределённые сети — единственный способ гарантировать долгосрочную доступность открытых моделей. Разделение «open-source» и «open-weight» критично: многие модели на Hugging Face имеют открытые веса, но не открытый код — именно веса — ключевой объект для сохранения. Сложные регистрации (требующие публикации на X или email) противоречат децентрализации и вызывают подозрения в спаме. После начального скачивания скорость загрузки падает — требуется оптимизация распределения пиров и использование CDN-подобных решений с торрентами.

Anubis — «весы душ» для HTTP-запросов, защищают сайты от ИИ-ботов. Вместо CAPTCHA требует перебора nonce, чтобы SHA-256(challenge+nonce) начиналась с 4 нулей (16 бит). Это Proof-of-Work, как в биткоине, но не майнинг.

Проблема: задача легка для дата-центра ИИ, но трудна для обычных пользователей без мощного железа.
Сайты ядра Linux (git.kernel.org, lore.kernel.org) теперь требуют этот PoW, что ломает скрипты и консольные клиенты.

Цифры

• Сложность 4 → 2¹⁶ ≈ 65 536 SHA-256 на токен.
• Токен живёт 7 дней.
• 11 508 «звёзд» GitHub ≈ столько сайтов с Anubis.
• На бесплатной e2-micro GCP: 3688 кБ/с SHA-256 → ≈ 230 000 хэшей/с.
• Для обхода всех сайтов за неделю: 11 508 × 65 536 ≈ 754 млн хэшей → 54 минуты CPU на одном ядре.
  Цена: копейки, даже в облаке. ИИ-вендору это ничто, а владельцу VPS-128 МБ — проблема.

Альтернативы

• Rate-limit, WAF, robots.txt, API-ключи, CDN, client-cert.
• Использовать Tor Browser (JS включён) или Selenium.
• Патчить curl/wget, добавляя JS-движок или готовый PoW-скрипт.
• Прокси-браузер (Puppeteer, Playwright) в headless-режиме.

Workarounds

• anubis-pass — консольный майнер на Go, решает задачу и выдаёт cookie.
• Пользовательские скрипты, которые запрашивают страницу, вычисляют PoW и продолжают сессию.

• Anubis — это PoW-заглушка, которая заставляет клиента выполнить небольшой вычислительный «тест» и получить токен на неделю; таким образом сервер получает идентификатор для рейт-лимита и борется с массовым «распылением» запросов ботами.
• Многие участники считают, что PoW легко обходится при наличии вычислительных ресурсов, но пока большинство AI-краулеров просто не стали заморачиваться, поэтому Anubis «работает» в реальности, хоть и не идеален.
• Критика: задержки 10–20 с на слабых устройствах, проблемы с доступом без JS, «аниме-девочка» вызывает у кого-то раздражение, а у кого-то ностальгию.
• Часть комментаторов предлагает альтернативы: микроплатежи, «человеческие» вопросы, лабиринты-ловушки, VPN-сети или просто блокировки по ASN.
• Самое главное: Anubis не решает проблему окончательно, но добавляет достаточно трения, чтобы заставить владельцев краулеров пересмотреть объёмы сканирования.