Компания Canonical переходит на единый двухнедельный цикл Stable Release Update (SRU) для ядра операционной системы Ubuntu. Ранее действовало разделение на два направления: полноценные обновления выходили каждые четыре недели, а ориентированные на безопасность релизы с экстренными патчами CVE выпускались в середине двухнедельного интервала. Теперь оба трека объединяются в единый процесс, который позволит выпускать новые сборки ядра еженедельно за счет смещения циклов.
Особенности нового двухнедельного процесса
Каждый новый цикл обновлений ядра Ubuntu начинается с недели интеграции патчей и подготовительных работ. На этом этапе команда разработчиков выбирает исправления для конкретных версий ядра, формирует пакеты и проводит базовые дымовые тесты для выявления очевидных ошибок до передачи сборки дальше.
После завершения первой недели такие сборки отправляются в репозиторий -proposed операционной системы Ubuntu. Там размещаются кандидаты в релизы до прохождения официальной сертификации, доступные продвинутым пользователям. Вторая неделя отводится под тестирование на оборудовании из программы Ubuntu Certified hardware testing. Сборки проверяют на различных типах машин, чтобы гарантировать стабильность перед финальным релизом.
Новый цикл стартует каждую неделю вне зависимости от статуса предыдущего, поэтому процесс тестирования и выпуска идет непрерывно. Если определенное обновление признают небезопасным для релиза, разработчики пообещали открыто предупреждать об этом и рекомендовать общие меры по защите системы. Для пользователей, которым критически важно получить исправления быстрее, Canonical предлагает использовать репозиторий -proposed, проводя собственные приемочные тесты без ожидания завершения полной сертификации.
Причины перехода на новый график обновлений
Необходимость столь масштабных изменений вызвана появлением автономных систем и языковых моделей, которые автоматизируют поиск уязвимостей. Искусственный интеллект и ИИ-агенты превратили обнаружение багов в ядре в непрерывный процесс, превосходящий по скорости работы любого человека-исследователя. Ранее в том же месяце фиксировалась масштабная нагрузка на вычислительные ресурсы git.kernel.org из-за автоматизированного сбора данных для обучения моделей.
Главной целью таких изменений является сокращение временного окна между публичным раскрытием уязвимости CVE и появлением патча. Компания стремится публиковать временные обходные пути в течение 24–48 часов после публикации CVE, переводя уязвимые системы в безопасное состояние до выхода официального исправления.
Дополнительные технические детали нового процесса
В основе изменений лежит трансформация традиционного подхода Canonical к доставке исправлений ошибок и патчей безопасности (Stable Release Update, или SRU) после релиза дистрибутива. Ранее ядро Ubuntu развивалось в рамках выделенного трека SRU, совмещавшего регулярные исправления и отдельные релизы безопасности.
Согласно новым правилам, процесс разбит на два четких этапа:
- Первая неделя: Команда разработчиков ядра отбирает фиксы для каждого конкретного ядра, собирает пакеты и проводит базовые дымовые тесты (smoke tests), отсеивая критические огрехи перед передачей сборок далее. По окончании этого этапа кандидаты в релизы попадают в специальный карман (pocket) -proposed, где они ожидают прохождения сертификации. Данный репозиторий доступен тем пользователям, которые точно знают, где искать такие сборки.
- Вторая неделя: Происходит аппаратное тестирование в рамках программы Ubuntu Certified hardware testing. Инженеры прогоняют сборки на самых разных типах машин, чтобы гарантировать отсутствие регрессий и сбоев в реальных условиях эксплуатации.
Для корпоративных клиентов и технических команд, не имеющих возможности ждать завершения полного двухнедельного цикла сертификации, репозиторий -proposed позиционируется разработчиками как ускоренный путь. Canonical рекомендует таким пользователям запускать собственные приемочные (acceptance) тесты непосредственно на находящихся там сборках.
Реакция на вызовы автоматизированного поиска угроз
Столь радикальное сокращение интервалов выпуска обусловлено появлением так называемых «кланкеров» (clankers) — автоматизированных ИИ-агентов и больших языковых моделей (LLM). Они поставили поиск уязвимостей на поток, осуществляя его с невероятной скоростью и в масштабах, недоступных ни одному исследователю-человеку.
Ярким подтверждением этого тренда стал инцидент, зафиксированный незадолго до анонса: ИИ-системы буквально истощали вычислительные ресурсы репозитория git.kernel.org, выполняя массивный веб-скрейпинг для сбора данных под обучение моделей.
Главным ориентиром для Canonical в этой гонке стало стремление публиковать временные обходные пути (workarounds) в течение 24–48 часов с момента публичного раскрытия CVE. Хотя полноценный патч может потребовать больше времени на подготовку и тестирование, оперативный обходной путь призван перевести затронутые системы в безопасное состояние сразу после обнародования уязвимости. В ситуациях, когда выпуск обновления признается небезопасным, компания обещает открыто информировать об этом сообщество и направлять администраторов к стандартным рекомендациям по системному харденингу.
