Obsidian минимизирует риски цепочек поставок, сознательно сокращая зависимости от стороннего кода. Приложение переиспользует или форкает небольшие модули, а для крупных библиотек вроде pdf.js или Mermaid использует версионно зафиксированные файлы с редкими обновлениями после тщательного тестирования. Это создаёт мелкую и контролируемую структуру зависимостей.

Все зависимости жёстко закреплены через lock-файлы, исключены пост-установочные скрипты, а обновления проводятся медленно и вручную — с изучением изменений, проверкой подзависимостей и тестами. Такой подход снижает вероятность попадания вредоносных обновлений и даёт время на обнаружение проблем до релиза.

• Пользователи выражают обеспокоенность уязвимой моделью безопасности плагинов Obsidian, которые имеют полный доступ к файлам.
• Обсуждается компромисс между использованием зависимостей и безопасностью: одни выступают за минимализм, другие — за осторожное обновление.
• Многие отмечают, что пост Obsidian игнорирует риски, связанные с плагинами, которые являются ключевой особенностью продукта.
• Высказывается критика в адрес Electron-архитектуры приложения из-за её ресурсоёмкости и потенциальных уязвимостей.
• Предлагаются альтернативы с меньшим количеством зависимостей и более нативными решениями, такие как Zim или Emacs.

pnpm 10.16

12 сентября 2025 · 3 мин чтения

Незначительные изменения

Новая настройка для отложенных обновлений зависимостей

Для снижения риска установки скомпрометированных версий пакетов вводится настройка minimumReleaseAge, которая задерживает установку недавно выпущенных зависимостей. Например, minimumReleaseAge: 1440 разрешает установку только пакетов, выпущенных не менее дня назад.

Исключения можно указать в minimumReleaseAgeExclude:

minimumReleaseAgeExclude:
  - webpack

Расширенная фильтрация зависимостей с помощью функций-поисковиков

Добавлена поддержка finders в .pnpmfile.cjs. Теперь можно искать зависимости не только по имени, но и по другим свойствам, например, по наличию определённой версии React в peerDependencies:

module.exports = {
  finders: {
    react17: (ctx) => {
      return ctx.readManifest().peerDependencies?.react === "^17.0.0";
    },
  },
};

Использование:

pnpm why --find-by=react17

Функции могут возвращать дополнительную информацию для вывода.

Исправления

• Устранено предупреждение о устаревании при запуске в Node.js 24.
• Добавлена проверка на точную версию semver для nodeVersion.
• Исправлена возможность публикации .tar.gz файлов через pnpm publish.
• Прерывание процесса Ctrl-C теперь возвращает ненулевой код выхода.

• Пользователи обсуждают стратегии защиты от вредоносных обновлений пакетов, включая задержку обновлений на несколько дней или месяцев и выборочное обновление только критических пакетов.
• Поднимается вопрос о том, как рассчитывается возраст пакета: важно использовать дату публикации в реестре, а не предоставленную автором, чтобы избежать подделки.
• Предлагаются альтернативные решения, такие как система разрешений для пакетов (à la Deno), разрешение зависимостей по хешу, а не по имени, и автоматизированный анализ кода ИИ перед публикацией.
• Отмечается, что подобные функции уже реализованы или разрабатываются в других менеджерах пакетов (Yarn, uv, Bun, npm-check-updates), и обсуждаются технические детали их реализации.
• Указывается на проблемы экосистемы npm: большой размер node_modules, высокая частота обновлений и автоматическое обновление минорных версий по умолчанию.
• Обсуждается роль автоматизированного сканирования новых пакетов security-компаниями как основного механизма обнаружения угроз, который может быть эффективнее индивидуальных задержек.
• Подчёркивается, что семантическое версионирование не всегда идеально соблюдается, и даже минорные обновления могут ломать совместимость, создавая риски при автоматическом обновлении.

Open Source — это один человек
Сокращённый перевод поста Джоша Брессерса

Публикация The Register, высмеивающая российского разработчика за то, что его утилита используется Пентагоном, — позор. На самом деле почти всё open-source ПО в мире пишут одиночки.

Проект ecosyste.ms индексирует 11,8 млн репозиториев. Из них 7 млн обслуживает один человек. Ещё 4 млн — данные о количестве мейнтейнеров отсутствуют, но большинство из них тоже «одиночки».

В экосистеме NPM картина та же:

• 4 млн пакетов → ~900 тыс. авторов (один человек — много проектов).
• Среди 13 тыс. самых скачиваемых пакетов (>1 млн загрузок в месяц) почти половина поддерживается одним человеком.
  Только при пороге в 1 млрд загрузок большинство проектов имеют команду >1 человека.

Вывод

• Риск цепочки поставок — не страна происхождения мейнтейнера, а один человек без ресурсов и оплаты.
• Уязвимость — не «русский хакер», а перегруженный разработчик, который может случайно или умышленно сломать критическую библиотеку.
• Обвинять таких людей в «предательстве» — неэтично и бесполезно.

Что делать? Однозначного рецепта нет, но начать стоит с признания проблемы и поддержки мейнтейнеров, а не травли.

• Проблема рисков цепочки поставок в OSS — это не инженерный, а управленческий вопрос: один автор, даже без злого умысла, создаёт уязвимость.
• Большинство пакетов NPM — одноразовые проекты одного человека; половина вообще не имеет активных мейнтейнеров.
• При «кончине» единственного мейнтейнера проект либо умирает, либо его форкают, либо приходит замена — зависит от размера аудитории и сложности кода.
• Критика статьи: автор путает скачивания CI/CD с реальным использованием, игнорирует реальное число контрибьюторов и подменяет статистику.
• DoD, как и любая крупная организация, использует Node/NPM для низкокритичных задач, а критичный код вендорится и аудируется.

Суть проблемы
В npm-реестр попали вредоносные версии пакетов Nx и связанных плагинов. Злоумышленники использовали временный доступ к npm-аккаунту @nxscope и опубликовали поддельные версии 19.8.0–19.8.2.

Затронутые пакеты

• nx
• @nx/angular, @nx/cypress, @nx/detox, @nx/devkit, @nx/esbuild, @nx/eslint-plugin, @nx/expo, @nx/express, @nx/jest, @nx/js, @nx/nest, @nx/next, @nx/node, @nx/playwright, @nx/plugin, @nx/react, @nx/rollup, @nx/storybook, @nx/vite, @nx/web, @nx/webpack, @nx/workspace

Что делать

1. Удалить вредоносные версии.
2. Установить официальные 19.8.3 или выше.
3. Проверить lock-файлы и CI на наличие подозрительных версий.

• Уязвимость в пакетах Nx: токен npm скомпрометирован, злоумышленники внедрили вредоносный код через post-install скрипты.
• Малварь ищет Claude Code / Gemini CLI и использует их как «живые» инструменты для поиска криптокошельков, ключей и других секретов.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать Bun (по умолчанию не запускает скрипты), Verdaccio для вендоринга и инструмент vet для сканирования.
• Рекомендуют разрабатывать в изолированных контейнерах/VM (cubbi, bubblewrap, firejail) и пересматривать каждую зависимость вместо «npm install наугад».
• Основной вывод: современные цепочки поставок и AI-агенты создают новый вектор атак «prompt-as-malware», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.