Профиль: Аноним (вход | регистрация) неRU opennet.me  
The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

В NPM 12.0 по умолчанию отключён запуск скриптов при установке пакетов

09.07.2026 20:35 (MSK)

Опубликован выпуск пакетного менеджера NPM 12.0, входящего в поставку Node.js и применяемого для распространения модулей на языке JavaScript. Новая версия примечательна прекращением по умолчанию запуска скриптов во время установки пакетов. Предполагается, что изменение усложнит проведение атак через компрометацию зависимостей и замедлит распространение червей, активируемых из установочных скриптов.

Для запрета автозапуска скриптов, указанных в package.json через параметры preinstall, install или postinstall, настройка allowScripts по умолчанию выставлена в значение "off". Выполнение подобных скриптов, а также запуск компиляции C/C++ кода утилитой node-gyp при наличии в пакете файла binding.gyp, теперь производится только при получении явной инструкции от пользователя. Помимо этого, параметры "--allow-git" и "--allow-remote" по умолчанию теперь выставлены в значение "none", что отключает автоматическую загрузку зависимостей из Git-репозиториев и по прямым ссылкам на сайты с tar-архивами.

Для организации запуска установочных скриптов следует использовать команду "npm approve-scripts", в качестве аргумента которой передаются имена пакетов, заслуживающих доверия, или опция "--all" для предоставления разрешения всем пакетам. Для сомнительных пакетов рекомендовано запускать команду "npm approve-scripts --allow-scripts-pending", которая выведет список претендующих на запуск скриптов. После проверки данных скриптов их можно разрешить командой "npm approve-scripts" и добавить в белый список в package.json.

Помимо этого анонсирован запрет использования в репозитории NPM GAT-токенов доступа (Granular Access Tokens), настроенных для выполнения действий без двухфакторной аутентификации (2FA). Начиная с августа подобные токены без дополнительного ручного подтверждения действий не позволят выполнять такие операции, как создание или удаление токенов, изменение профиля, пароля или email, настройка двухфакторной аутентификации, генерация кодов восстановления, изменение прав доступа и управление сопровождающими.

В январе 2027 года намерены запретить прямую публикацию пакетов с использование токенов, обходящих 2FA. При этом пакеты можно будет опубликовать в staging-разделе, в котором они будут находиться до ручного подтверждения релиза сопровождающим. После ручного подтверждения опубликованные пакеты станут доступны для установки пользователями.

Для автоматической публикации предлагается использовать механизм "Trusted Publishers", основанный на использовании стандарта OpenID Connect (OIDC) и токенов аутентификации с ограниченным временем действия, которыми обмениваются внешние сервисы и каталог пакетов для подтверждения операции публикации пакета вместо использования традиционных паролей или постоянных токенов доступа к API.

  1. Главная ссылка к новости (https://github.blog/changelog/...)
  2. OpenNews: Атакующие встроили вредоносное ПО в 32 NPM-пакета Red Hat
  3. OpenNews: В 42 NPM-пакета TanStack интегрирован самораспространяющийся червь
  4. OpenNews: Раскрыты подробности захвата учётных данных сопровождающего NPM-пакет axios
  5. OpenNews: Утечка кода инструментария Claude Code из-за забытого в NPM-пакете map-файла
  6. OpenNews: При помощи червя Shai-Hulud скомпрометировано 600 NPM-пакетов
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/65878-npm
Ключевые слова: npm
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (27) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.5, q (ok), 22:04, 09/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Неужели кто-то догадался, что пакет = метаданные + статичные файлы? Если ваш пакетный менеджер гоняет скрипты при установке-удалении, то это фигня на палочке, а не пакетный менеджер. Если твой дистр не уместился в наипростейшую концепцию "пакет = метаданные + статичные файлы", то твой дистр -- галиматья. На данный момент, все дистры галиматья, кроме NixOS/Guix.
     
     
  • 2.9, Аноним (9), 22:44, 09/07/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Скажи это твоим любимым деб пакетам
     
     
  • 3.12, Аноним_83 (?), 23:10, 09/07/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >деб пакетам

    ты про зипарь, набитый скриптами запускающимися от рута?

     
  • 2.11, Аноним (11), 22:54, 09/07/2026 [^] [^^] [^^^] [ответить]  
  • +2 +/
    когда ставишь какой-нибудь ssh сервис, то ключи /etc/ssh/ssh_host_* должны поставляться как статичные файлы или генерироваться специальным скриптом, который просто идет отдельно от ssh?
    Т.е. можно ли сделать любой пакетный менеджер нормальным, если вынести все скрипты в отдельный обязательный пакет и дергать их в зависимости от "метаданных"?
     
     
  • 3.14, Аноним_83 (?), 23:12, 09/07/2026 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >когда ставишь какой-нибудь ssh сервис, то ключи /etc/ssh/ssh_host_* должны поставляться как статичные файлы или генерироваться специальным скриптом, который просто идет отдельно от ssh?

    это вообще не задача для пакетного менеджера. после установки делаешь руками или генеришь скриптом, который запускаешь руками

     
     
  • 4.20, Аноним (-), 23:54, 09/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    задача пакетного менеджера оставить пользователя с нерабочим приложением и необходимостью запускать какие-то скрипты с какими-то параметрами, угу.

    А скрипт я должен сам написать или где-то взять? Его можно было бы положить в пакет, но в чем тогда будет отличие от запуска скрипта тем же пакетным менеджером?

     
     
  • 5.25, Аноним2 (?), 00:09, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    В ansible конфигурация сервера описывается одними лишь YAML-файлами, никаких скриптов. И это работает.
     
     
  • 6.28, Аноним (-), 00:19, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    вот только анзибл это не пакетный менеджер. И одними yaml-файликами там дело не обходится — во-первых jinja2 во все поля, а во-вторых там предлагается писать модули на питоне на все нестандартные хотелки
     
     
  • 7.31, Аноним (31), 03:03, 10/07/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     
  • 4.33, Аноним (33), 03:27, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > делаешь руками

    У нас в ДЦ смонтировали 20 стоек. Чтобы через час везде руками нагенерил. Время пошло.

     
  • 3.23, Аноним (23), 00:00, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ничего не мешает оформить это действие в виде метаданных пакета. Пусть пакетный менеджер сам выполняет необходимые действия, которые описаны в метаданных.
     
     
  • 4.29, Аноним (-), 00:25, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Чтобы пакетный менеджер выполнил какие-то действия, которые описаны в метаданных, он должен знать как это сделать — либо его код содержит всю логику для всех пакетов (для простых случаев работает), либо где-то лежит россыпь скриптов.

    Ну и еще момент, что описание "необходимых действий" это и есть по факту скрипт, который выполняет пакетный менеджер

     
  • 3.30, q (ok), 02:48, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Догадываешься ли ты о том, что ключи — это часть состояния системы? sshd.service может иметь ExecStart=башскрипт.sh, который, в свою очередь, сгенерит тебе ключи, а уже потом выполнит exec sshd. Любой нормальный сервис должен уметь запускаться, имея абсолютно пустую state directory.

    И именно в этом примере, ключи надобно хранить в /var, а не в /etc, ибо /etc может быть смонтирован как readonly. Писать в /etc -- абсолютно трэшовая практика, о чем многие здесь присутствующие даже не догадываются. /etc должен формироваться еще ДО запуска системы, точка. Буквально. Как только ядро смонтировало /etc, всё. Нельзя туда писать. Вообще. Даже если "просто хочу подправить конфиг быстренько". Нельзя и точка. Хочешь изменить поведение системы -- протестируй новый конфиг в виртуалке, затем создай новую generation хоста, а затем перезагрузись.

     
     
  • 4.34, windows10 (ok), 04:02, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > Догадываешься ли ты о том, что ключи — это часть состояния системы?

    Догадываешься ли ты, что человек лишь привел пример необходимости запуска триггера, а не спорит о ключах?

    DKMS тебе при установке драйвера кто будет генерить?

    Кто будет добавлять запись в загрузчик при установке нового ядра?

    Локаль кто будет генерить при обновлении glibc?

    > Любой нормальный сервис должен уметь запускаться, имея абсолютно пустую state directory.

    Уметь запускаться, и функционировать как нужно - два разных по своей сути действия.

     
     
  • 5.35, q (ok), 04:46, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > человек лишь привел пример необходимости запуска триггера

    А я привел демонстрацию того, что такая необходимость надуманна. Практический пример: в NixOS ни один пакет не имеет скриптов. Там это тупо не предусмотрено. Невозможно добавить скрипт. Понял? Значит, как-то обошлись, и populate state directory on service run -- лишь один из многих способов обойтись без скриптов.

    > DKMS тебе при установке драйвера кто будет генерить?

    Ты понимаешь бредовость своего вопроса? Сборка происходит ДО формирования пакета, а не ПОСЛЕ его установки мля. Если в твоем дистре при установке пакета происходит СБОРКА, то это хрен собачий, а не дистр. В нормальных дистрах цикл такой: сборка -> получился пакет -> установили пакет. А у тебя хвост виляет собакой: установили пакет -> СБОРКА НАХРЕН.

    > Локаль кто будет генерить при обновлении glibc?

    Опять-сызнова. Генерация -- это часть сборки мля. Сборка предшествует пакету.

     
  • 2.19, Аноним (19), 23:40, 09/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    > На данный момент, все дистры галиматья, кроме NixOS/Guix.

    flake.nix почему-то за скобками...
    Сравнивать пакеты дистрибутива и NPM - такое себе.

     

  • 1.6, Аноним (6), 22:07, 09/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    не поможет
     
  • 1.7, Ivan_83 (ok), 22:31, 09/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    А вот в windows XP до этого додумались раньше лет на 20 :)
     
  • 1.10, Аноним_83 (?), 22:52, 09/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +3 +/
    Не прошло и 500 лет
     
  • 1.13, localhostadmin (ok), 23:11, 09/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    А зачем это вообще было нужно? Не представляю в каких сценариях может понадобиться выполнение произвольного кода при установке пакета
     
     
  • 2.16, Аноним (16), 23:18, 09/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    ldconfig при любом обновлении в /usr/lib
     
  • 2.26, Аноним (-), 00:11, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +1 +/
    по разному бывает. Иногда в скриптах идет сборка нативных компонентов, которые линкуются к библитекам с хоста. Из альтернатив — носить все зависимости с собой или поддерживать пакеты для дистрибутивов.
     
  • 2.27, Аноним (27), 00:15, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • +/
    Ну вот раньше был флеш популярным. flashplugininstaller скачивал с сайта адобе и настраивал блоб.
     
  • 2.32, Аноним (31), 03:05, 10/07/2026 Скрыто ботом-модератором     [к модератору]
  • +/
     

  • 1.21, Аноним (21), 23:56, 09/07/2026 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Что это за ЯП такой которому нужен свой пакетный менеджер и столько суеты с ним? Зачем его вообще использовать?
     
     
  • 2.22, Аноним (27), 00:00, 10/07/2026 [^] [^^] [^^^] [ответить]  
  • –1 +/
    node.js
     

  • 1.24, Аноним (24), 00:02, 10/07/2026 Скрыто ботом-модератором [﹢﹢﹢] [ · · · ]     [к модератору]
  • +1 +/
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2026 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру