Новые правила безопасности пакетных менеджеров: что исправили pnpm, pipx и Renovate
В конце октября вышли обновления, которые затрагивают разные этапы работы с программными зависимостями: pnpm исправил ошибки при распаковке сжатых данных и обработке криптографических операций, pipx ускорил обновление сертификатов для общей копии pip, а Renovate научился предлагать исправления уязвимостей в транзитивных пакетах, найденных в lock-файле.
pnpm: защита памяти и безопасная работа с подписью
В pnpm 12.16, опубликованном 27 октября, исправили обработку данных, сжатых алгоритмом zstd. Ошибки при работе с памятью могли привести к её раскрытию или сбоям выделения ресурсов, если менеджер получал специально подготовленный входной файл.
Ещё одно изменение касается операций подписи общих артефактов и обработки данных авторизации в pnpm и pnpr. Криптографическая библиотека, задействованная в этих процессах, в некоторых случаях работала неодинаково долго в зависимости от секретных значений. Теоретически атакующий, способный наблюдать за временем операций, мог использовать эти различия для восстановления секрета.
Реальная возможность подобной атаки зависит от многих условий: используемого алгоритма, процессора и компилятора, а также от того, насколько точно злоумышленник может измерять время выполнения. Библиотеку обновили, чтобы устранить известные отклонения от постоянного времени работы.
Однако обновление pnpm само по себе не гарантирует, что все проекты защищены. 30 октября разработчики отдельно предупредили об автономных сборках менеджера. Если проект закреплён за pnpm 10 или 11, он может продолжить запускать старую сборку, даже когда в системе установлен pnpm 12. В состав автономной версии входит собственный Node.js, поэтому она способна сохранять доверие к скомпрометированным сертификатам eMudhra.
Ранее для этой проблемы были выпущены исправленные версии pnpm 10.34.8 и 11.28.8. Проверять следует не только глобально установленный менеджер, но и версию, зафиксированную в настройках проекта и используемую в системах непрерывной интеграции.
pipx: общая копия pip обновляется быстрее
Версия pipx 1.18.7 вышла 28 октября и повысила минимальную версию общего pip до 26.2.2. В этой версии pip обновлён набор сертификатов после инцидента, связанного с eMudhra.
Особенность pipx в том, что многие установленные через него приложения используют общую копию pip. Поэтому обновление pip в системном Python не всегда устраняло проблему для приложений, которые были установлены или обслуживаются через pipx.
Раньше обновление общей копии могло зависеть от планового обслуживания, происходившего раз в 30 дней. Теперь pipx заменяет устаревший pip при следующей установке или обновлении приложения, а также при его запуске через менеджер. Если нужно выполнить обновление немедленно, доступна команда `pipx upgrade-shared`.
Автоматическое обслуживание может быть отключено настройкой или специальным флагом. В таком случае обновление общей копии придётся запустить вручную. Кроме того, приложения могут содержать собственные экземпляры библиотеки certifi - они обновляются отдельно. Если приложение устанавливалось с помощью uv, необходимо обновить и сам uv.
Renovate обнаруживает уязвимости в транзитивных зависимостях
В Renovate 44.189.0, опубликованном 27 октября, расширили обработку предупреждений безопасности. Бот может предлагать обновления для уязвимых транзитивных зависимостей, сведения о которых есть в lock-файле, даже если они не указаны напрямую в манифесте проекта.
Это важно для приложений, зависящих от длинных цепочек библиотек. Разработчик может напрямую подключить один пакет, который, в свою очередь, устанавливает множество других. Уязвимая библиотека в такой цепочке иногда отсутствует в основном файле конфигурации, но отражается в lock-файле. Теперь Renovate может подготовить запрос на обновление, если ограничения прямой зависимости допускают переход на исправленную версию.
Ранее такие записи могли пропускаться при выборе кандидатов для обновления. Теперь предупреждение проверяется до того, как Renovate решит не обрабатывать пакет. При этом учитываются правила версий конкретного источника пакетов. Настроенные пользователем запреты и списки игнорируемых зависимостей продолжают действовать.
Для работы функции в GitHub должны быть включены граф зависимостей и предупреждения Dependabot, а приложению Renovate необходимо предоставить доступ к этим сведениям. После обновления бота командам стоит проверить, появились ли предложения исправить пакеты, уже отмеченные как уязвимые в lock-файле.
Что стоит проверить разработчикам
Обновление менеджера зависимостей - только один пункт в проверке безопасности. Важно убедиться, что проект действительно запускает актуальную версию, а не старую сборку, закреплённую в конфигурации. Особенно внимательно стоит проверять CI-среды: там часто используются отдельные версии инструментов и кэшированные окружения.
Также полезно проверить, каким способом устанавливаются пакеты и откуда загружаются сертификаты. Обновление системного инструмента не всегда меняет библиотеки, скопированные внутрь виртуального окружения или приложения. Для pipx это означает необходимость учитывать и общую копию pip, и собственные экземпляры certifi, и использование uv.
Lock-файл следует регулярно пересматривать и обновлять вместе с манифестом зависимостей. Он показывает фактическое дерево пакетов, включая вложенные компоненты, поэтому помогает обнаруживать риски, незаметные при проверке только прямых зависимостей.
Автоматические боты ускоряют устранение проблем, но не заменяют контроль со стороны команды. Перед слиянием обновления нужно проверить совместимость исправленной версии с приложением, а также убедиться, что изменение действительно затрагивает уязвимый пакет, а не только пересобирает часть окружения.
В том же новостном обзоре упоминалась утилита DiscImageStudio: она преобразует изображение в данные, которые можно нанести на CD, DVD или Blu-ray при помощи обычного пишущего привода. Также сообщалось об уязвимости sshhole в OpenSSH на системах Linux с musl, способной затрагивать учётные записи без пароля, и о новых возможностях взаимодействия больших языковых моделей. Эти темы не связаны напрямую с обновлениями пакетных менеджеров, но напоминают, что безопасность разработки зависит не от одного инструмента, а от всего программного окружения.
