Hacker News Digest

Вышли внеплановые критические патчи GitLab для Community и Enterprise Edition: версии 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 и 18.11.13. Всем, кто разворачивает GitLab самостоятельно, настоятельно рекомендуют немедленно обновиться. Облачный GitLab.com уже работает на исправленной версии, а арендаторы GitLab Dedicated на 19.3.5-internal0 и 19.4.2-internal0 и новее защищены и могут ничего не делать.

Патч закрывает несколько уязвимостей. Самая серьёзная — критическое целочисленное переполнение в компиляторе регулярных выражений. Далее идут уязвимости высокой степени риска: некорректная аутентификация при автосвязывании учётных записей через OmniAuth и LDAP по email, а также отравление кэша в эндпоинтах обнаружения OAuth/OIDC. Средний уровень риска — неправильный контроль доступа к полю email в GraphQL для рабочих элементов, неполное применение блокировки членства SAML/LDAP на уровне инстанса, позволяющее несанкционированно добавлять участников, и раскрытие внутренних учётных данных в заголовках ответов. Детали уязвимостей раскроют через 90 дней после выпуска.

Патч содержит миграции базы данных: на одноузловых установках обновление пройдёт с простоем, а на многоузловых при соблюдении процедур обновления без простоя — без него. Обычные миграции входят в 19.4.3 и 19.3.6, пост-развёртываемые — в 19.4.3.

Обсуждение дополняет новость о критических патчах GitLab. Пользователи @molf и @zahlman пояснили, что уязвимость вызвана ошибкой в движке регулярных выражений Ruby (onigmo), а не в самом GitLab. @miduil сообщил о еще одной проблеме с regex, позволяющей неавторизованно обращаться к эндпоинту, однако @dvdkon уточнил, что для этого нужна аутентификация и загрузка вредоносного org-mode файла. @artooro, @merb и @mqus отметили, что встроенный проверщик обновлений GitLab часто ошибочно требует обновления даже после установки последней версии, а его отключение занимает много времени. Для быстрой проверки версии на узлах @beaconflint рекомендует команду `gitlab-rake gitlab:env:info`. @yoyohello13 и @131hn заметили, что из-за еженедельных патчей ручное обновление стало невозможным, поэтому советуют использовать AI-агентов или автоматические CI-процессы. @minraws в связи с рисками самохостинга рекомендует строго фильтровать исходящий трафик (например, через Tailscale). @tptacek указал, что оценка CVSS 10.0 без контекста не отражает реальный уровень риска. В то же время @hobofan и @choilive поспорили о влиянии ИИ на безопасность: первый считает текущую ситуацию худшей в истории ИТ из-за массовых уязвимостей, второй — началом «золотого века» с ростом инвестиций в автоматизированные сканеры.

SAML — протокол аутентификации на основе XML, созданный в 2002 году комитетом OASIS из четырёх конкурирующих стандартов — стал основой индустрии единого входа (SSO). Он успешно решал задачу централизованной аутентификации в эпоху роста SaaS, особенно в академии и корпоративной IT, но его сложность оказалась катастрофической: XML-подписи, требующие проверки через непрозрачные библиотеки вроде libxmlsec, стали источником уязвимостей, которые большинство реализаций просто игнорируют. Дизайн «по комитету» привёл к избыточности, а архитектура — к хрупкости, несовместимости и трудностям в поддержке.

Современные альтернативы, особенно OpenID Connect (OIDC) на основе JSON и OAuth 2.0, значительно проще, безопаснее и легче интегрируются. Ведущие компании вроде Fly.io и Tailscale уже отказались от SAML, доказав, что даже для крупных корпоративных клиентов OIDC — жизнеспособный выбор. Для провайдеров идентичности путь отказа от SAML долгий, но пошаговый: остановить новые SAML-интеграции, перевести клиентов на OIDC, назначить дату отключения. SAML заслужил своё место в истории как катализатор SSO, но его пора заменить — как и XML, как и устаревшие подходы, которые больше не оправдывают свою цену.

SAML остается актуальным в корпоративной среде из-за поддержки IdP-инициированных потоков и устойчивости в закрытых сетях, несмотря на свою сложность, а OIDC не решает всех проблем, особенно в условиях изоляции от публичных провайдеров.

• Совет: Для интеграции SAML в JVM-приложения рекомендуется использовать pac4j — он упрощает работу с различными фреймворками и скрывает сложность низкоуровневых деталей.

• SAML и OIDC оба страдают от сложных реализаций: SAML — из-за XMLDSIG и канонизации, OIDC — из-за уязвимостей JWT (none-алгоритм, отсутствие проверки audience).

• Спор: Некоторые утверждают, что SAML уязвим из-за XML-подписей, но другие отмечают, что OIDC с JWT имеет не менее опасные уязвимости, включая возможность смены алгоритма подписи на 'none'.

• Проблема SAML не в XML как таковом — в 2002 году XML был логичным выбором, а альтернативы (ASN.1, кастомный формат) были не проще и не безопаснее.

• Совет: Для enterprise-продуктов поддержка SAML обязательна, так как корпоративные клиенты требуют совместимости с их существующими IdP, и отказ от SAML делает продукт невосприимчивым к рынку.

• SAML поддерживает IdP-инициированные потоки, что критично для корпоративных SSO, тогда как OIDC требует инициации от SP, что не всегда возможно в закрытых сетях.

• Спор: Одни считают, что SAML безопасен благодаря встроенной подписи, защищающей от MITM, другие возражают, что уязвимости в реализациях (например, проверка подписи по HMAC из атакуемого документа) делают его ненадежным.

• Реализации SAML часто ошибочно доверяют всему документу после проверки подписи, а не только подписанной части, что позволяет атакующему вставлять произвольные данные.

• Совет: Для снижения сложности SAML можно поддерживать только дайджесты топ-10 провайдеров и игнорировать нишевые реализации — это уменьшает объем поддержки без потери функциональности.

• Проблемы SAML не в стандарте, а в его реализациях: библиотеки libxml2 и другие неправильно обрабатывают XML-ноды, что позволяет обходить аутентификацию через MITM.

• Совет: Индивидуальные решения вроде IndieAuth и новых паттернов на базе OAuth, FedCM и DIDs обещают децентрализованную аутентификацию, но пока не получили широкой поддержки.

• OIDC не может работать с приватными IdP без публичного доступа, тогда как SAML поддерживает интеграцию в изолированных корпоративных сетях без внешних зависимостей.

• Комитетная разработка SAML привела к 'кухонному ракетостроению' — избыточным функциям, которые усложняют реализацию, в отличие от фокусированных решений вроде WireGuard.

• Совет: При интеграции SAML всегда проверяйте, что подпись применяется только к конкретной части документа, а не ко всему телу — это частая ошибка в реализациях.

• Большинство компаний не хотят поддерживать децентрализованную аутентификацию, потому что предпочитают монетизировать SSO через дополнительные услуги: анти-спам, восстановление паролей, контроль создания аккаунтов.

GitHub.com переживает массовый сбой: более 20 % запросов к веб‑интерфейсу и API возвращают ошибки, а скачивание архивов и исходных файлов репозиториев падает до 50 %. Самые критичные проблемы — с доступом к Pull Requests, Issues, Actions, Pages, Webhooks и Copilot, а также с аутентификацией через SAML, OIDC, SCIM и Team Sync.

Ключевой факт: почти половина попыток загрузки кода не проходит, что делает текущие разработки почти невозможными. Команда GitHub уже работает над компенсацией и публикует регулярные обновления о ходе расследования.

Обсуждение подтверждает, что сбои GitHub перестали быть редкими и стали системной проблемой, вызывающей массовый переход на альтернативы, включая самоприюты вроде Gitea и Forgejo, а также ставящую под сомнение устойчивость централизованной платформы как критической инфраструктуры разработки.

• Многие участники отмечают, что частота сбоев GitHub достигла уровня, при котором платформа больше не может считаться надежной основой для CI/CD и критичных рабочих процессов.

• Самоприюты на базе Gitea, Forgejo и Woodpecker CI активно используются в продакшене как альтернатива GitHub, особенно среди тех, кто ценит контроль и отказ от зависимости от облачных провайдеров.

• Проблемы GitHub не связаны исключительно с ростом трафика от LLM — ключевым фактором называется плохое управление и отсутствие инвестиций в масштабируемость инфраструктуры.

• Совет: Рекомендуется всегда иметь зеркало репозитория в виде bare repo, чтобы обеспечить доступ к коду во время сбоев GitHub, даже если веб-интерфейс недоступен.

• Совет: Для критичных операций во время сбоев рекомендуется использовать gh CLI для одобрения и слияния pull requests, так как он может работать, когда веб-интерфейс недоступен.

• Совет: Самоприюты с Gitea и Woodpecker CI могут работать при затратах около $30/месяц на инфраструктуру, что дешевле, чем стоимость GitHub для команды, и обеспечивает полный контроль.

• Спор: Одни считают, что рост трафика от LLM — основная причина сбоев, другие настаивают, что это следствие управленческих ошибок Microsoft, а не нагрузки, приводя в доказательство исторические данные об отказах.

• Спор: Некоторые утверждают, что GitHub стал «too big to fail» и теперь не несет реальной ответственности за сбои, тогда как другие считают, что пользователи должны сами искать альтернативы, а не ждать улучшений.

• Состояние GitHub на статус-странице часто не отражает реальную доступность — пользователи фиксируют сбои, которых нет в логах, что подрывает доверие к официальной отчетности.

• Совет: Предлагается создать самоприют с полной синхронизацией PR и Issues между локальным инстансом и GitHub, чтобы работать офлайн и синхронизировать изменения при восстановлении сервиса.

• Ценность GitHub — не в git, а в PR, Issues, Actions и системе идентификации, и заменить эту экосистему сложнее, чем просто сменить хостинг.

• Совет: Для управления Issues без GitHub предлагается использовать простую структуру директорий в репозитории с файлами issue.md, что позволяет обойтись без веб-интерфейса и использовать стандартные git-команды.

• Частые сбои GitHub вызывают рост недоверия и моральное выгорание у разработчиков, что приводит к эмоциональному отторжению платформы, даже если она технически удобна.

• Отсутствие публичных пост-мортемов после регулярных сбоев усиливает подозрения в системной небрежности со стороны Microsoft и отсутствии прозрачности в управлении инфраструктурой.

• Совет: Пользователи рекомендуют пересмотреть политику использования GitHub как единственного источника правды — внедрять дублирование репозиториев и CI/CD пайплайнов на альтернативных платформах для устойчивости.

This is starting to feel like Twitter. For a variety of reasons, we had a centralized place where everyone of a particular set of persuasions could connect, and this had outsize benefits for the community as a whole. That place is becoming untenable, and with the loss of goodwill and stability, the… — @Arubis