Менеджер пакетов Lix, как независимый вариант популярного менеджера Nix, долгое время пользовался доверием пользователей благодаря стабильности и удобству работы. Однако в июне 2025 года в Lix была обнаружена критическая ошибка корректности, которая существенно повлияла на системы многих пользователей. Причиной стала регрессия, введенная вместе с исправлением уязвимости CVE-2025-52992, что ставит под угрозу целостность и стабильность деривационных сборок. В данной статье подробно рассмотрим, что за ошибка была выявлена, почему она возникла, какие версии Lix затронуты, а также какие меры можно предпринять для восстановления и защиты системы. Суть возникшей проблемы связана с нарушением корректности хранения путей в системе.
Поправка, призванная закрыть уязвимость безопасности, привела к неожиданному ошибочному поведению при сборке дериваций — частей системы, ответственных за сборку и управление программным обеспечением. В результате некоторые пути в хранилище могли оказаться либо полностью отсутствующими, либо невидимо недействительными для системы. Такое состояние напрямую сказывалось на работе, вызывая нестабильность и даже сбои. По словам команды Lix, основные причины ошибки связаны с тем, что при сборке дериваций создавались выходные данные, часть которых отсутствовала в локальном хранилище. Это могло происходить, если часть выходов была получена через удаленного сборщика либо размещена в хранилище на другом хосте через инструменты развертывания, вроде colmena.
Такая ситуация является распространенной в распределённых и многопользовательских средах, что увеличивает вероятность появления проблемы и масштаб её воздействия. Важным аспектом проблемы стал факт, что ошибка затронула именно определенные версии Lix. Конкретно среди версий 2.91.2, 2.
92.2 и 2.93.1 были выявлены случаи нарушения корректности. При этом более свежие версии 2.
91.3, 2.92.3 и 2.93.
2 уже содержат исправления и не подвержены этому багу. Отмечается, что проблема была выявлена на Linux, однако поскольку корень проблемы платформонезависимый, вероятность появления аналогичной неисправности на других системах, включая Darwin (macOS), также существует. Для пользователей крайне важно знать, как правильно реагировать на выявленную ошибку. Главное — своевременно остановить сервисы, которые могут усугубить состояние системы. Рекомендуется остановить работу сборщика мусора Nix и демона Nix, чтобы предотвратить дальнейшие повреждения.
Затем следует загрузить статический бинарный файл Nix, независимый от поврежденного интерпретатора, чтобы безопасно выполнять команды восстановления без риска усугубить ситуацию. Одной из ключевых рекомендаций является запуск проверки целостности хранилища командой nix-store с параметрами верификации и ремонта. Данный процесс позволит выявить и исправить отсутствующие или поврежденные пути. Важно выполнять эти действия от имени пользователя root для обеспечения доступа к необходимым ресурсам. Если при проверке не обнаружено ошибок, это означает, что система находится в безопасном состоянии.
Однако если нарушение будет выявлено, необходимо выполнять восстановление отдельных путей с помощью дополнительного параметра для восстановления. После успешного проведения проверки и ремонта рекомендуется пересобрать систему, чтобы перейти к стабильной и надежной версии Lix. Для этого можно использовать статический бинарный файл Nix с последующей сборкой конфигурации. Пользователи, не использующие флейки, применяют команду nix-build, а приверженцы флейков — экспериментальные возможности nix с поддержкой فلэйков. После сборки выполняется смена конфигурации и окончательное переключение на обновленную и безопасную версию системы.
Немаловажно помнить, что некоторые распространенные команды, такие как nix-store --delete --ignore-liveness, использовать крайне опасно в текущей ситуации. Применение подобных команд может привести к необратимому разрушению системных зависимостей и полностью вывести систему из строя. Познавая распространенность проблемы, команда Lix предоставила несколько вариантов решения для пользователей. Во-первых, рекомендуется обновить Lix до одной из версий, не подверженных багу. Существуют специальные версии с патчами, которые исключают регрессию, обеспечивая стабильность работы.
Во-вторых, для тех, кто предпочитает не обновляться немедленно, может быть актуальным возврат к предыдущим, хоть и уязвимым, версиям, обеспечивающим стабильную работу без риска регрессии. В случаях, когда система уже повреждена, специалисты советуют воспользоваться стандартными методами восстановления. Загрузка живого ISO-образа с рабочим Nix, монтирование корневого раздела и проведение проверки хранилища с помощью статического бинаря — основные шаги к успешному восстановлению. После этого можно вернуться к стандартным процедурам перехода на исправленную версию. Для продвинутых пользователей и администраторов предусмотрены рекомендации по самостоятельному применению патчей в nixpkgs с дальнейшей интеграцией в текущий процесс сборки Lix.
Доступны официальные ресурсы с инструкциями по оверлеям и переопределению атрибутов для интеграции необходимых исправлений без полной переустановки системы. Команда Lix тщательно контролировала ситуацию с момента получения информации об ошибке. Публикация CVE и начало расследования пришлись на конец июня 2025 года. За несколько дней была не только выявлена суть проблемы, но и разработаны способы восстановления и обновления, что позволило минимизировать нанесенный ущерб. Система поддержки Lix работает круглосуточно, предоставляя помощь через все каналы, включая электронную почту и сообщества пользователей.
Профессионалы и энтузиасты открытого программного обеспечения должны воспринимать подобные инциденты как напоминание о важности регулярных обновлений и резервного копирования. Несмотря на то, что ошибки в софте — неизбежная часть развития, правильное реагирование, своевременная диагностика и наличие надежных инструментов восстановления способствуют быстрой стабилизации работы систем. Lix, как проект с открытым исходным кодом, продолжает развиваться благодаря усилиям сообщества и волонтеров, которые оперативно реагируют на вызовы и обеспечивают безопасность пользователей. Сложившаяся ситуация стала проверкой на прочность доверия к проекту, которая была успешно пройдена благодаря прозрачности коммуникаций и ответственному подходу к решению проблем. Таким образом, пользователи Lix должны внимательно следить за обновлениями и в случае необходимости применять описанные методы восстановления.
Остановки служб, загрузка статических бинарей, проверка целостности хранилища, а также своевременный переход к безопасным версиям — ключевые меры для сохранения работоспособности и безопасности системы. Надежный подход к управлению пакетами и системными конфигурациями позволит избежать критических сбоев и сохранить стабильность рабочих процессов. В заключение стоит отметить, что изучение и применение практик выявления и исправления ошибок в менеджерах пакетов является важной составляющей для каждого системного администратора и пользователя, стремящегося к максимальной надежности своей инфраструктуры. Ошибка в Lix напоминает о необходимости поддержки экосистемы open source, а также о важности совместной работы специалистов для быстрого решения возникающих проблем и повышения качества программного обеспечения.
