pnpm 11.4 — релиз с явным фокусом на безопасность JavaScript supply chain. Он закрывает слабое место, которое часто недооценивают: установка выглядит «зафиксированной» lockfile, но при некоторых условиях всё ещё может принять изменённые байты, утекшие credentials или опасные пути.
Главное изменение простое: если скачанный tarball не совпадает со значением integrity в lockfile, pnpm теперь по умолчанию завершает установку ошибкой. Именно такого поведения большинство команд и ждёт от lockfile, закоммиченного в репозиторий.
Lockfile теперь жёстче реагирует на изменённые байты#
Самое важное исправление связано с проверкой integrity у tarball.
До pnpm 11.4, если hash скачанного tarball не совпадал с lockfile, pnpm мог тихо заново разрешить пакет через registry и перезаписать зафиксированное значение integrity. Это помогало некоторым «сломавшимся» установкам восстановиться автоматически, но одновременно ослабляло lockfile как границу безопасности.
Риск здесь не абстрактный. Если registry, proxy, mirror или заново опубликованный пакет отдавал другой контент, чистая машина могла принять байты под контролем атакующего, хотя проект поставлялся с закоммиченным lockfile. Снаружи установка всё ещё выглядела так, будто использует pinned dependency metadata. На практике байты уже не были pinned.
Теперь pnpm выдаёт ERR_PNPM_TARBALL_INTEGRITY, когда скачанный tarball не совпадает с lockfile. В релиз добавили явный аварийный обход: pnpm install --update-checksums. Этот flag узко предназначен для обновления зафиксированных integrity-значений по тому, что registry отдаёт сейчас; когда обход срабатывает, pnpm печатает warning.
Разница важна. Обновлять checksums иногда нормально. Делать это молча во время обычной установки — ровно то место, где защита ломается. Новое поведение заставляет пользователя или CI job явно принять это решение.
В релизе также сказано, что routine refresh operations не должны молча перезаписывать locked integrity. --fix-lockfile сохраняет свою документированную роль: заполнять отсутствующие записи в lockfile. Его не трактуют как общий обход integrity-проверок.
Registry tarball без integrity больше не проходит#
pnpm 11.4 также fail-closed, когда записи registry tarball в lockfile не содержат integrity metadata.
Раньше worker, который распаковывал скачанный tarball, пропускал hash verification, если integrity-значения не было. Затем он создавал новое integrity-значение из непроверенных байтов. Так появлялся путь атаки: если злоумышленник мог одновременно изменить lockfile и отдать изменённый контент по указанному tarball URL, он мог установить подменённый пакет без ошибки.
В релизе описан правдоподобный сценарий pull request: удалить поле integrity, сослаться на изменённый tarball URL и позволить install process принять и «благословить» эти байты. Теперь pnpm отклоняет это уже при чтении lockfile с ошибкой ERR_PNPM_MISSING_TARBALL_INTEGRITY.
Исключение ограниченное. Git-hosted tarballs и локальные file: tarballs не попадают под это правило, потому что их байты привязаны иначе: через commit SHA в git-host URL или через локальный путь под контролем пользователя. Это важная оговорка: pnpm не делает вид, что у всех типов artifacts одинаковая модель доверия.
Credentials теперь привязаны к нужному registry#
Исправление с credentials выглядит тихо, но для команд оно тоже важно.
Проблема касалась unscoped per-registry settings: auth tokens или client TLS credentials. Если такие значения были заданы в одном source конфигурации, а другой слой позже указывал pnpm на другой registry, pnpm мог отправить credential уже туда. Во враждебной или просто неправильно настроенной среде это означает утечку token, предназначенного для одного registry, в другой.
Теперь pnpm при загрузке переписывает каждую unscoped per-registry credential setting в URL-scoped форму. Он берёт registry, объявленный в том же source, или default npm registry, если registry там не задан. После такой перепривязки более поздний слой конфигурации уже не может «утащить» unscoped credential к другому registry: credential уже pinned к URL, который имел в виду автор настройки.
Практический вид — тот, который командам и так стоит использовать:
//registry.example.com/:_authToken=...
//registry.example.com/:cert=...
Когда pnpm перескоупливает настройку, он выводит deprecation warning: показывает, куда setting была pinned и как записать её напрямую. В release notes также сказано, что npm уже много лет outright rejected unscoped credentials, а pnpm планирует убрать поддержку в future major release.
Одна деталь важна: CA settings намеренно не rescoped. Обоснование такое: это trust anchors, а не credentials, и многие корпоративные TLS inspection setups зависят от того, что они применяются глобально. Это компромисс, а не универсальное одобрение MITM proxying.
Вредоносные lockfiles и patches теряют трюки с путями#
Несколько исправлений в pnpm 11.4 отклоняют опасные значения до того, как lower-level tooling сможет интерпретировать их рискованным образом.
Git resolutions теперь отклоняют ссылки не в формате SHA. Если commit field у git resolution не 40-character hexadecimal SHA, pnpm отклоняет его до вызова git. Источник отмечает опасный класс значений на SSH или local-file transports, где вредоносный lockfile мог протащить command-like input в путь вызова git. Исправление строгое: принять настоящий SHA, отклонить всё остальное.
Patch files тоже ограничены. Patch headers, которые ссылаются на пути вне директории patched package, теперь отклоняются. Раньше вредоносный patch file, добавленный в pull request, мог записывать, удалять или переименовывать произвольные файлы, доступные пользователю, который запускает pnpm. На машине разработчика это уже серьёзно. В CI это может стать проблемой credentials или build-system — зависит от того, к чему runner имеет доступ.
Dependency aliases получили похожее усиление. Aliases с path-traversal segments, например имена, оформленные так, чтобы выбраться в .git/hooks, отклоняются при чтении из package manifest или при создании symlink в node_modules. Источник описывает риск так: вредоносный registry package использует transitive dependency key, чтобы заставить pnpm создать symlinks по путям, выбранным атакующим, вне ожидаемого места.
Это не самые эффектные bugs. Это bugs на install surface. Поэтому они и важны: package managers находятся между недоверенными package metadata, машинами разработчиков, CI runners, registries, mirrors, patches и tools, которые можно вызвать через shell.
Trusted publisher metadata теперь требует provenance#
pnpm 11.4 меняет отношение к trusted-publisher metadata. В релизе сказано, что trusted publisher metadata считается strongest trust evidence только при наличии provenance.
Это разумное ужесточение. Publisher identity metadata полезна, но сильнее, когда связана с provenance, который подтверждает, как был произведён artifact. Без provenance трактовать publisher metadata как сигнал с максимальной уверенностью — значит переоценивать то, что реально проверено.
Источник не даёт здесь длинной policy model, поэтому безопасное прочтение узкое: pnpm снижает вес доверия к publisher metadata, когда provenance отсутствует. Не стоит превращать это в утверждение, что вся publisher metadata без provenance бесполезна, или что provenance сам по себе решает проблему доверия к пакетам.
Остальные исправления операционные, но тоже полезные#
В релиз вошли не только security fixes. Есть улучшения, которые важны прежде всего для команд с большими workspaces или новыми runtime workflows.
Одно deploy-related исправление касается nested installs, которые падали при config dependencies. В релизе указано, что deploy directory никогда не устанавливает config dependencies, поэтому install engine, который они задают, отсутствует на диске; теперь nested install их пропускает.
pnpm также ограничивает concurrent project manifest reads при listing large workspaces, чтобы снизить нагрузку на filesystem. Runtime handling получил путь ERR_PNPM_BAD_RUNTIME_VERSION для плохих runtime versions. Logging улучшили после того, как pnpm автоматически добавляет entries в workspace configuration: сообщение теперь направляет пользователей к документированной setting, которая ставит такие обновления за prompt, вместо ссылки на внутренний термин “loose mode”.
Это не headline релиза. Но такие изменения уменьшают неоднозначность в крупных репозиториях, где непонятное поведение установки быстро становится security-adjacent проблемой просто потому, что никто не может уверенно сказать, что именно сделал tool.
Что командам сделать сейчас#
Тестирование upgrade стоит начать с установок, которые раньше «лечили» себя сами.
Если CI начал падать с ERR_PNPM_TARBALL_INTEGRITY, воспринимайте это как сигнал, а не шум. Проверьте, не устарел ли lockfile, не отдаёт ли registry или proxy изменённый контент, не был ли package version republished или inconsistently mirrored. Если изменение ожидаемое, используйте pnpm install --update-checksums осознанно и просмотрите lockfile diff.
Проверьте .npmrc и связанную конфигурацию pnpm на unscoped credentials. Перенесите tokens и client certificate settings в URL-scoped form. Не ждите future major release, где compatibility path уберут.
Pull requests, которые меняют lockfiles, patch files, dependency aliases или git resolutions, стоит ревьюить подозрительнее, чем обычные version bumps. pnpm 11.4 уже отклоняет несколько опасных форм, но общее правило остаётся: package-manager metadata влияет на install environment почти как исполняемый ввод.
Правильный вывод из pnpm 11.4 — не «установки пакетов теперь безопасны». Это не так. Более точная и сильная формулировка уже: pnpm убрал несколько мест, где locked install мог тихо перестать быть locked.