pnpm 11.27 закрив небезпечний сценарій у shared store та ізолював кеші приватних registry

Команда pnpm випустила стабільну версію 11.27 з набором виправлень для безпеки, приватних registry, глобальних інсталяцій та великих workspace. Найважливіша зміна стосується завантажуваних runtime: архів Node.js тепер розпаковується у випадково названу директорію всередині store. Раніше передбачуваний шлях створював можливість для іншого користувача спільного сховища підкласти символічне посилання й перенаправити запис за межі store. У release notes це виправлення пов'язане з advisory GHSA-vwc7-r8mq-g2x9.

Чому shared store потребував додаткового захисту

Спільний store заощаджує місце та прискорює інсталяції, але водночас стає межею довіри. Якщо кілька облікових записів або CI-job мають доступ до одного сховища, передбачувана тимчасова директорія дає атакувальнику шанс підготувати файлову структуру до початку розпакування. Символічне посилання може змусити процес із ширшими правами записати файли не туди, куди очікує package manager.

Випадкове ім'я робочої директорії прибирає можливість надійно вгадати ціль до операції. Це не замінює коректних дозволів на файловій системі, ізоляції runner та регулярного очищення середовища, але суттєво звужує сценарій атаки. Командам, які ділять pnpm store між користувачами, контейнерами або CI-виконавцями, варто оновитися в першу чергу.

Кеші приватних registry більше не змішуються

Друга помітна зміна стосується Artifactory, Nexus, AWS CodeArtifact і GitLab Packages. Кілька репозиторіїв можуть працювати на одному хості, але відрізнятися шляхом у URL. Раніше метадані таких registry потрапляли до спільної кеш-директорії. Через це запит до одного репозиторію іноді отримував версії, integrity hash або адресу tarball з іншого та завершувався помилкою ERR_PNPM_TARBALL_URL_MISMATCH.

У pnpm 11.27 ключ кешу враховує повну адресу registry, включно зі схемою та шляхом. HTTP і HTTPS на одному хості також розділені: метадані, отримані незахищеним каналом, не можуть бути повторно використані для HTTPS-конфігурації. Після оновлення перша інсталяція заново завантажить метадані, але сам package store залишиться недоторканим.

Менше ризику втратити глобальні інструменти

Команди pnpm add -g, pnpm update -g і pnpm remove -g тепер спочатку повністю перевіряють встановлену групу пакетів. Якщо manifest відсутній, пошкоджений або не читається, операція завершується до активації чи видалення. Раніше частково прочитаний стан міг призвести до зміни глобальних bin або install-директорій, залишивши середовище в неповному стані.

Для робочих станцій це означає менший шанс раптово втратити CLI після невдалого update. Для базових образів CI зміна ще важливіша: помилка стає атомарнішою, а попередня інсталяція зберігається, замість того щоб утворити напівоновлений шар.

Registry з .npmrc знову має пріоритет

Виправлено й маршрутизацію запитів після pnpm login. Registry або @scope:registry, зазначений у проєктному .npmrc, тепер переважає адресу, яку глобальний config.yaml зберіг разом з обліковими даними. Раніше логін до одного сервера міг непомітно спрямувати інсталяцію іншого проєкту не до того приватного registry.

Окремо GitHub Actions updater зупиняється, якщо посилання на action змінилося під час визначення доступних версій. Посилання на GitHub server більше не повинні розкривати credentials, а віддалені сервери мають використовувати HTTPS; HTTP дозволено лише для loopback-адрес.

Що змінилося для повсякденної розробки

Параметр fetch-timeout тепер означає час без прогресу, а не загальну тривалість запиту. Таймер перезапускається з кожним отриманим фрагментом, тому великий архів через повільне з'єднання не буде обірваний, доки дані продовжують надходити. Зависле з'єднання, як і раніше, завершиться після timeout.

Для monorepo виправлено читання packageManager, devEngines.packageManager і runtime pins з кореневого package.json, коли lockfileDir перенесено. Перевірка peers більше не вважає залежності з workspace:^, workspace:~ або workspace: невиконаними незалежно від версії пов'язаного пакета. Також автоматично додаються відсутні транзитивні peer dependencies, коли проєкти workspace використовують спільну залежність на різній глибині.

Скрипти збірки та контроль довіри

Якщо patch додає залежності preinstall, install, postinstall або binding.gyp, pnpm тепер бачить потребу у збірці, але спочатку просить схвалення. Пакет з'явиться серед Ignored build scripts, доки адміністратор явно не дозволить запуск. Це узгоджує функціональність patch із моделлю безпеки, де сторонній код не повинен автоматично виконуватися під час install.

Новий параметр trustPolicyExcludePrune може прибирати з trustPolicyExclude записи версій, яких більше немає у свіжому lockfile. Очищення навмисно не запускається для workspace без спільного lockfile, бо пакет, що здається зайвим одному проєкту, може бути потрібним іншому.

Що перевірити після оновлення

• Оновіть pnpm у CI та на машинах, які використовують store спільно, і перевірте права доступу до нього.
• Запустіть одну чисту інсталяцію для кожного приватного registry: кеш метаданих буде сформовано заново.
• Перевірте скрипти, які парсять pnpm cache list або pnpm cache list-registries, бо формат назв директорій змінився.
• Перегляньте Ignored build scripts після застосування patches, що додають lifecycle scripts або binding.gyp.
• Для SPDX-процесів повторіть генерацію SBOM: timestamp тепер записується цілими секундами й має проходити суворі валідатори.

Практичний висновок

pnpm 11.27 — не косметичне обслуговування старої гілки. Реліз закриває файловий сценарій у спільному store, відокремлює метадані registry за повною адресою, обережніше працює з credentials і робить глобальні зміни менш руйнівними. Найбільшу користь отримають організації з self-hosted registry, загальними CI-кешами та великими monorepo. Перед масовим розгортанням варто виконати пробну інсталяцію, перевірити cache automation і зафіксувати очікувану політику запуску build scripts.