Середина июня принесла в мир свободного программного обеспечения сразу несколько событий, которые на первый взгляд живут в разных плоскостях, но на деле складываются в одну картину: инфраструктура, на которой держится современный Linux, проходит через ускоренное обновление. Вышел новый кернел с давно обещанной файловой системой, истекает старый криптографический сертификат загрузки, разработчики самой используемой утилиты в интернете объявили перерыв, а пользовательский репозиторий Arch Linux пережил одну из крупнейших атак на цепочку поставок в своей истории. Разберём каждое событие по порядку и заодно покажем, что в этой цепочке объединяет файловую систему, сертификат и заражённые пакеты.
Новый драйвер NTFS избавляет Linux от двадцатилетней зависимости от обходных решений
Главная новость релиза 7.1, вышедшего 14 июня, касается файловой системы NTFS, которую разработала Microsoft для своих операционных систем. До этого момента у пользователей Linux было три варианта работы с такими разделами, и ни один не выглядел как окончательное решение. Старый драйвер ядра умел только читать данные. Пользовательский драйвер NTFS-3G, работающий через FUSE, умел и читать, и писать, но платил за это производительностью из-за постоянных переключений контекста между пространством пользователя и ядром. Третий вариант, драйвер NTFS3 от Paragon Software, попал в ядро в 2021 году с полноценной поддержкой чтения и записи, но дальнейшая разработка застопорилась, а доверие сообщества к нему так и не стало всеобщим.
Разработчик Намджэ Чон, уже известный сообществу как автор драйвера exFAT, взялся за переработку оригинального драйвера NTFS ещё в 2022 году, после отчёта о фактически осиротевшем состоянии NTFS3. По его собственным словам, последние четыре года он потратил на то, чтобы добиться полноценной поддержки записи с учётом современных тенденций ядра, включая iomap и отказ от устаревшего механизма buffer head в пользу folio, а также повысить производительность, обеспечить стабильное сопровождение и добавить утилитарную поддержку для NTFS на Linux, включая fsck.
Технически новый драйвер построен вокруг той же высокопроизводительной модели ввода вывода, что используется в XFS, и опирается на современное управление памятью через структуры folio вместо устаревших буферных заголовков. Это не просто восстановление работоспособности NTFS, а полноценная перестройка поддержки этой файловой системы так, чтобы она внутренне вела себя как современная файловая система Linux, что представляет собой серьёзный концептуальный сдвиг по сравнению с прежним подходом, когда NTFS воспринималась лишь как слой совместимости. Цифры производительности впечатляют: разработчик заявляет об ускорении однопоточной записи на 3 до 5 процентов и многопоточной записи на 35 до 110 процентов по сравнению с существующими решениями.
Путь нового кода в основную ветку ядра получился не совсем гладким. При первой попытке слияния Линус Торвальдс отменил пул-реквест, обнаружив проблемы в том, как был оформлен запрос в Git, однако Чон оперативно отправил исправленную версию, которая удовлетворила требованиям Торвальдса, и на момент публикации новый драйвер был окончательно влит в дерево ядра. Сам Торвальдс назвал произошедшее emoционально окрашенным словом, которое можно перевести как воскрешение NTFS, отметив масштаб переработки. Важная деталь для администраторов и пользователей: старый драйвер NTFS3 пока остаётся в дереве ядра как доступная альтернатива, новый код можно включить через параметр конфигурации NTFS_FS, что даёт время на тестирование без риска сломать существующие системы.
Практическая польза очевидна для всех, кто живёт на стыке двух экосистем. Дизайнеры и видеомонтажёры получают возможность редактировать материалы прямо с внешних SSD-накопителей, отформатированных в NTFS, без риска повредить метаданные. Разработчики на системах с двойной загрузкой смогут делиться рабочими каталогами проектов между Windows и Linux без костылей в виде exFAT или FAT32. Системные администраторы получат полноценный доступ на запись при восстановлении данных с загрузочных носителей Linux. Есть и ограничения, которые честно признают сами авторы: зашифрованные тома с технологией BitLocker пока остаются недоступны без отдельного пользовательского помощника, а теневые копии томов открыты только на чтение, хотя поддержку шифрования планируют добавить в одном из последующих минорных релизов при условии, что криптографические крючки пройдут юридическую проверку.
Кроме NTFS ядро 7.1 принесло масштабную чистку устаревшего кода и улучшения для современного оборудования
Файловая система забрала всё внимание заголовков, но релиз 7.1 устроен гораздо шире. Окно слияния для этого выпуска закрылось после двух месяцев интенсивной работы, с более чем 15000 коммитов от почти 2000 разработчиков. Результат затрагивает практически каждый слой системы, от планировщика процессов до сетевого стека.
Управление памятью получило заметное обновление: подсистема свопа модернизирована с удалением старой карты подкачки, что привело к повышению эффективности и снижению потребления памяти, а кернел также устранил давнюю проблему, при которой завершённые контрольные группы оставались зависшими из-за закреплённых страничных блоков памяти. Для тех, кто работает с контейнерами и виртуализацией, это означает меньше утечек ресурсов на долго работающих системах.
Сторона безопасности тоже не осталась без внимания. Ядро 7.1 ввело более строгие ограничения доступа по умолчанию к памяти процессов через файловую систему proc, добавило новые точки подключения для модулей безопасности применительно к оверлейным файловым системам и доменным сокетам Unix, а модуль Landlock воспользовался новым сокетным хуком, чтобы предложить дополнительные варианты политик. Параллельно с укреплением защиты произошла масштабная зачистка устаревшего кода: из дерева ядра удалена поддержка нескольких архитектур x86 эпохи 486, включая M486, M486SX и ELAN, всего убрано более 140000 строк кода, включая хост-контроллеры PCMCIA и множество устаревших сетевых драйверов и протоколов. Сетевой стек тоже почистили: поддержка UDP Lite исчезла полностью, а IPv6 теперь обязательно встраивается прямо в кернел или полностью отключается, поскольку модулем его больше собрать нельзя.
Любителям современного железа достанутся свои подарки. Введён драйвер macsmc-power, позволяющий отображать состояние батареи, напряжение и температуру на ноутбуках MacBook с чипом Apple Silicon серий M1 и M2, а на консолях Steam Deck OLED устранена давняя ошибка, связанная со звуком. Добавлены улучшения для компонентов от Qualcomm, Rockchip, Tenstorrent, ESWIN, Loongson и Lenovo, в том числе поддержка геймпада Lenovo Legion Go S. Энтузиасты процессоров Intel оценят включение технологии гибкой обработки возврата и доставки событий, известной как FRED, по умолчанию, что улучшает работу современных чипов с прерываниями.
Следующий цикл разработки уже запущен. После выхода 7.1 скоро откроется окно слияния для следующей крупной серии ядра, версии 7.2, ожидаемой в середине или конце августа 2026 года, а первый релиз-кандидат для публичного тестирования появится спустя две недели, 28 июня 2026 года. Темп разработки ядра остаётся прежним: новая крупная версия примерно каждые два с половиной месяца, и каждая приносит сотни мелких изменений, которые редко попадают в заголовки, но в сумме определяют, насколько комфортно живётся на современном железе.
Истечение сертификата Microsoft заставляет пользователей Linux обновить загрузчик до конца месяца
Параллельно с выходом нового ядра разворачивается совсем другая история, которая касается не функциональности, а доверия на самом базовом уровне загрузки системы. 27 июня 2026 года истекает сертификат Microsoft Corporation UEFI CA 2011, и это прямо касается миллионов установок Linux на современном оборудовании.
Чтобы понять масштаб, нужно вспомнить механику Secure Boot. Эта функция микропрограммы UEFI проверяет цифровые подписи на каждом этапе загрузки системы, от первого загрузчика до самого кернела, и не позволяет запускаться непроверенному коду. Поскольку производители оборудования не выдают отдельный сертификат каждому дистрибутиву Linux, роль удостоверяющего центра для стороннего программного обеспечения взяла на себя Microsoft. Компания подписывает своим закрытым ключом небольшой первый загрузчик, известный как shim, который затем проверяет следующие компоненты цепочки, включая GRUB и сам кернел.
Начиная с октября 2025 года Microsoft подписывала shim сразу двумя разными ключами, старым из 2011 года и новым сертификатом подписи Microsoft UEFI CA 2023, а после июня 2026 года подписывать новым материалом смогут уже только вторым ключом. Здесь важно различать два эффекта истечения, потому что именно эта путаница породила волну паники в сообществе. Прошивка UEFI не проверяет дату истечения сертификата, поскольку у неё нет надёжного способа узнать показания аппаратных часов в момент загрузки, поэтому истечение срока не равносильно отзыву. Истечение сертификата влияет на подпись, а не на проверку: публичный сертификат 2011 года уже лежит в базе доверия прошивки и останется там, существующий уже подписанный shim был подписан тогда, когда ключ был действителен, а прошивка проверяет подпись относительно сертификата, который был действителен на момент подписания, а не относительно сегодняшней даты, поэтому система, успешно загружающая Linux сегодня, продолжит успешно загружаться и после 27 июня без всяких исключений.
Проблема возникает не сегодня и не завтра, а позже, когда дистрибутивы начнут выпускать обновлённые версии shim или загрузчика, подписанные исключительно новым ключом 2023 года. Если такое обновление окажется подписано только новым ключом, а в прошивке конкретного компьютера не зарегистрирован новый сертификат, обновление просто не загрузится. Особенно уязвимы старые системы: физические серверы, ноутбуки и настольные компьютеры, которые больше не получают обновлений прошивки от производителя, а также различные устройства-приставки, никогда не видевшие обновления BIOS или UEFI, могут столкнуться с проблемами в тот момент, когда потребуется обновление загрузчика или shim после истечения срока действия.
Крупные дистрибутивы уже подготовились заранее. По состоянию на 10 июня Red Hat выпустила новую версию shim, подписанную несколькими сертификатами одновременно, для всех поддерживаемых выпусков RHEL восьмой, девятой и десятой версий для архитектуры x86_64, и поскольку новый shim подписан и сертификатом 2011 года, и сертификатом 2023 года, он будет успешно загружаться на любой машине, где зарегистрирован хотя бы один из этих двух сертификатов. Похожим путём пошли другие крупные проекты: сообщество Linux с 2022 года постепенно переходит на новый сторонний сертификат Microsoft UEFI CA, действующий до 2035 года, и дистрибутивы вроде Ubuntu, Fedora и openSUSE уже поставляют обновлённые загрузчики shim, подписанные обоими сертификатами сразу.
Помимо самого широкого сертификата UEFI CA есть и более узкий нюанс, касающийся системных администраторов крупных парков техники. Связанный сертификат Microsoft Corporation KEK CA 2011 истекает даже раньше, уже 24 июня, и отвечает за подпись обновлений доверенной базы прошивки db и запрещающей базы dbx, что важно для того, как новые ключи в конечном счёте регистрируются или как блокируются скомпрометированные. Структурная перестройка коснулась и третьих сторон, чьи устройства тоже зависят от подписей Microsoft. Вторая функция ключа 2011 года, подпись сторонних опциональных прошивок ROM для видеокарт и сетевых адаптеров, выделена в отдельный сертификат 2023 года, что является реальным улучшением безопасности, позволяя средам доверять загрузчику shim без необходимости одновременно доверять произвольным прошивкам оборудования от сторонних производителей, хотя эта новизна означает, что отдельные нетипичные ситуации ещё продолжают всплывать.
Практический совет для рядового пользователя укладывается в одно действие. Стоит проверить список сертификатов в собственной прошивке командой mokutil с параметром db, убедиться в наличии сертификата UEFI CA 2023, и при его отсутствии включить службу LVFS, обновляющую прошивку напрямую от производителя оборудования, либо выполнить обновление пакетов загрузчика через менеджер пакетов своего дистрибутива. Для систем с двойной загрузкой порядок действий имеет значение: сначала Windows должна установить новые сертификаты через собственный механизм обновления, затем прошивка UEFI должна закрепить эти сертификаты в цепочке доверия, и только после этого shim RHEL или Fedora, подписанный новым сертификатом, сможет успешно загрузиться. Для большинства людей на поддерживаемом дистрибутиве с оборудованием, которое до сих пор получает поддержку производителя, ситуация разрешается обычным плановым обновлением пакетов.
Создатель curl объявляет летний отпуск от разбора отчётов об уязвимостях
Третья история этого июня выглядит почти неожиданной на фоне технических релизов: главный разработчик утилиты curl Дэниел Стенберг объявил, что проект целый месяц не будет принимать и обрабатывать отчёты об уязвимостях. Проект curl не будет принимать или каким-либо образом обрабатывать сообщения об уязвимостях на протяжении июля 2026 года, и эту инициативу назвали летом блаженства, а форма подачи заявок на платформе Hackerone будет приостановлена с 1 июля.
Лето блаженства стартует 1 июля 2026 года в полночь по центральноевропейскому времени, а приём заявок возобновится 3 августа в девять утра по тому же часовому поясу. Решение касается не только платной платформы Hackerone. Адрес электронной почты для вопросов безопасности тоже окажется в тупике, поскольку команда не будет обрабатывать и не станет уделять внимание сообщениям об уязвимостях, отправленным этим путём, хотя по электронной почте отчёты об уязвимостях curl и в обычное время принципиально не принимает. Решение потянуло за собой и сдвиг календаря релизов: как прямое следствие лета блаженства, чтобы дать команде больше времени на разбор накопившихся проблем в начале августа, дата выхода версии 8.22.0 перенесена на две недели вперёд и теперь запланирована на 2 сентября 2026 года.
Причина отпуска оказалась далеко не банальной усталостью от рутины, а вполне конкретной технологической проблемой, знакомой многим открытым проектам последних лет. По словам Стенберга, с весны 2026 года наблюдается всплеск качественных и подробных отчётов, число которых достигло четырёх, пяти раз больше показателей 2024 года и почти вдвое больше показателей 2025 года, при этом в среднем поступает больше одного отчёта в день, а чем дольше затягивается ответ, тем больше растёт нерассмотренная очередь. Ключевая деталь в том, что речь не о банальном спаме. Участники киберсообщества на одной из площадок заметили, что curl обработал девятнадцать отчётов за пятнадцать дней на платформе Hackerone, и почти все из них оказались бесполезными или малозначимыми, написанными ИИ-агентами. Даже если многое из этого сгенерировано искусственным интеллектом, это не очевидная бессмыслица, отчёты получаются подробными и обширными, и Стенбергу приходится проверять отчётов в четыре, пять раз больше, чем в 2024 году, причём каждый требует огромных трудозатрат.
Решение получило широкую поддержку среди коллег по open source цеху. Стенберг прямо предложил и другим поддерживающим открытые проекты разработчикам присоединиться к подобной практике, написав, что если кто-то из читателей вместе со своими проектами также хочет принять участие в лете блаженства 2026 года, достаточно просто сделать это и сообщить ему, и он, конечно, будет это поощрять. При этом проект не оставляет платящих клиентов без поддержки: у всех, кто имеет платный контракт на поддержку, обслуживание продолжится в полном объёме даже во время этого перерыва. Важная оговорка для пользователей, которые переживают за безопасность инфраструктуры в этот месяц: обычные сообщения об ошибках и предложения по исправлению кода, не связанные с уязвимостями, по прежнему можно подавать через систему issues и pull request на платформе для совместной разработки, как и раньше. Трекеры задач и запросов на слияние кода проекта останутся открытыми в течение всего периода.
История получила неожиданное продолжение, связанное с самой природой потока низкокачественных отчётов. Источник всплеска подробных, но в основном пустых заявок журналисты связали с массовым использованием ИИ-моделей для автоматического поиска уязвимостей в открытом коде, причём отдельно отмечалось, что один из крупных коммерческих ИИ-сервисов, который чаще других называли причастным к росту числа находок, в те же недели подвергся серьёзным ограничениям доступа по решению поставщика, хотя на момент написания причины этого шага оставались не до конца ясны. При этом сам curl от этой конкретной модели за месяц получил всего одно действительно стоящее сообщение об уязвимости, что хорошо иллюстрирует общую проблему: объём отчётов растёт куда быстрее, чем их полезность.
Атака на пользовательский репозиторий Arch Linux показала слабость системы усыновления заброшенных пакетов
Четвёртое крупное событие июня касается безопасности экосистемы пакетов, и оно прямо демонстрирует, как механизм, придуманный для удобства сообщества, может стать точкой входа для масштабной атаки. 11 и 12 июня в пользовательском репозитории Arch Linux, известном как AUR, была раскрыта операция, которую исследователи назвали кампанией Atomic Arch.
Механика атаки строилась на особенностях самого репозитория. Атакующие систематически усыновляли около 1500 заброшенных пакетов AUR, изменяя их инструкции сборки так, чтобы устанавливался вредоносный npm-пакет atomic-lockfile и его варианты, причём это вредоносное программное обеспечение, написанное на языке Rust, было разработано для сбора учётных данных и кражи чувствительных сведений с рабочих станций разработчиков и сред непрерывной интеграции, работающих на Arch Linux или производных дистрибутивах. Хитрость заключалась в том, что код самого пакета не менялся: атака использует доверие, заложенное в экосистемы открытого программного обеспечения, обходя традиционные методы обнаружения за счёт изменения только скриптов сборки, а не кода самого пакета.
Технические детали внедрения вредоносного кода объясняют, почему атаку было трудно заметить при поверхностном просмотре. В файле сборки PKGBUILD добавлялся npm как зависимость, менялись контактные данные сопровождающего на адреса gmail, а затем подключался установочный скрипт пакета, который в свою очередь выполнял команду npm install atomic-lockfile axios got. Один из участников технического обсуждения точно подметил суть проблемы: сама по себе строка с npm может не показаться подозрительной неспециалисту, но внезапная смена контактных данных у всех сопровождающих сразу должна была вызвать вопросы. Отдельное наблюдение касается момента срабатывания вредоносного кода: для заражённых пакетов установка npm была помещена именно в install-файл, который связывает хук, запускаемый после установки пакета, поэтому сам PKGBUILD при простом просмотре выглядел совершенно нормально, и ничего вредоносного не происходило при сборке пакета через makepkg, которая обычно выполняется не от имени суперпользователя, проблема возникала только в момент установки пакета менеджером pacman, который и запускал постустановочный хук.
Масштаб инцидента нарастал стремительно в течение одного дня. День начался с того, что в пользовательском репозитории AUR обнаружили более 400 заражённых пакетов, а к концу дня разработчики Arch Linux посчитали, что устранили все известные им вредоносные коммиты, хотя итоговое число поражённых пакетов превысило 1500. Вторая волна атаки продемонстрировала, что злоумышленники не остановились на первой методике. Кампания включала две волны атак, и первая использовала пакетный менеджер npm для установки atomic-lockfile, js-digest или lockfile-js через файлы PKGBUILD или install, тогда как вторая волна, использующая пакет js-digest, опиралась на менеджер bun, причём обе волны устанавливали программу для кражи информации и руткит на основе технологии eBPF, нацеленные на учётные данные разработчиков, данные браузера и секреты систем непрерывной интеграции и доставки.
Команда Arch Linux отреагировала открытым предупреждением для всего сообщества. Пользователям AUR продолжают рекомендовать проверять все изменения в файлах PKGBUILD и установочных скриптах при каждом обновлении, особенно в это время, а при обнаружении подозрительных коммитов в используемом пакете обращаться к команде Arch через почтовую рассылку aur general с подробной информацией. Параллельно проект принял временные ограничительные меры. Репозиторий AUR оставался доступным, а пакеты продолжали скачиваться, однако регистрация новых учётных записей оказалась недоступна, и страница регистрации возвращала ошибку 503 о временной недоступности сервиса, что хотя и не было официально объявлено, явно говорило о намеренной блокировке одной из точек входа на время расчистки.
Важное уточнение касается того, кого атака не затронула. Целью атаки стали исключительно заброшенные пакеты AUR, тогда как активно поддерживаемые пакеты не пострадали, и происходящее никак не связано с официальными пакетами Arch Linux. Это разграничение важно для оценки реального риска: подавляющее большинство пользователей, которые ставят официальные пакеты из основных репозиториев и аккуратно следят за обновлениями активно поддерживаемых проектов AUR, оказались в безопасности. Прямо затронуты пользователи и организации, устанавливающие или обновляющие пакеты AUR на системах на базе Arch, включая самостоятельно размещённые исполнители непрерывной интеграции и среды разработчиков, при этом нет доказательств прямого влияния на платформы, отличные от Arch, или на исполнители, размещённые непосредственно на GitHub.
Случившееся вновь подняло старый спор о принципах устройства пользовательских репозиториев в принципе. Один из участников сообщества подчеркнул, что подобная история показывает, как AUR не может стать будущим десктопного Linux, поскольку репозиторий полностью нерегулируем, ограничен преимущественно одним семейством дистрибутивов и требует от пользователя серьёзного внимания, включая чтение файлов PKGBUILD, тогда как на платформе Flathub за всё время не было обнаружено ни единого случая вредоносного кода благодаря строгим требованиям публикации и обязательной ручной проверке каждого приложения перед выходом, причём флэтпак-пакеты при этом доступны на любом дистрибутиве. Практический вывод напрашивается сам собой: процедура усыновления заброшенных пакетов, придуманная как способ сохранить полезный код живым, оказалась той самой дверью, через которую прошла атака, и сообществу теперь предстоит решить, какими барьерами эту дверь укреплять без потери удобства, ради которого AUR изначально создавался.
Что объединяет все четыре истории и чего ждать дальше
На первый взгляд кернел с новой файловой системой, истекающий криптографический сертификат, отпуск разработчика утилиты для передачи данных и заражённый пользовательский репозиторий не имеют друг с другом ничего общего. Но если посмотреть внимательнее, во всех четырёх случаях речь идёт об инфраструктуре доверия, которая годами работала на автопилоте и теперь одновременно проходит проверку на прочность.
NTFS долгие годы оставалась тем самым неловким мостиком между двумя мирами, который технически работал, но никогда не вызывал полного доверия у системных администраторов, рисковавших данными при каждой операции записи. Сертификат подписи загрузчика держал доверие между производителями оборудования и операционными системами больше десяти лет без единого публичного сбоя, и теперь этот механизм проходит первую крупную ротацию ключей на практике, а не в теории. Утилита curl является частью буквально каждого второго устройства с доступом в интернет, и нагрузка на единственного человека, отвечающего за её безопасность, выросла настолько, что пришлось официально объявить перерыв, иначе риск ошибки от переутомления стал бы выше риска от пропущенной уязвимости. А история с AUR показывает, что доверие внутри сообщества разработчиков открытого кода тоже не бесконечно эластично: механизм, придуманный для удобства, без проверок неизбежно становится мишенью.
Для рядового пользователя Linux из всего этого вытекает простой практический список действий на ближайшие недели. Стоит обновить пакеты загрузчика и проверить наличие нового сертификата в прошивке до конца июня, не откладывая это на потом просто потому, что система пока загружается без проблем. Стоит присмотреться к новому драйверу NTFS, если работа постоянно требует обмена файлами с Windows-системами, но для рабочих машин разумно подождать, пока код пройдёт пару циклов стабилизации в дистрибутивах. Если в работе используются пакеты из AUR, стоит взять привычку проверять файлы сборки перед каждым обновлением, особенно если у пакета недавно сменился сопровождающий. А если в команде есть собственный открытый проект, страдающий от потока низкокачественных автоматических отчётов, пример curl показывает, что временная пауза в приёме заявок не выглядит постыдным решением, а наоборот может оказаться единственным разумным способом не утонуть в шуме и вернуться к работе со свежими силами.
Канал сайта в Telegram
Канал сайта на YouTube