Автор столкнулся с загадкой в Nix: имея бинарник Ruby, он не мог найти соответствующий .drv файл, хотя база данных и кэш NixOS указывали на его существование. Команда nix-store --query выдавала ошибку, а файл отсутствовал в системе, хотя nix derivation show находил совершенно другой .drv файл для того же бинарника. Это противоречило его пониманию работы Nix.

Ключ к разгадке — "fixed-output derivations" (FOD). Автор демонстрирует, что изменения в FOD (даже добавление мусорных атрибутов) изменяют путь самого .drv файла, но не затрагивают выходной путь (/nix/store/...). Это свойство "modulo" означает, что выходные пути зависят только от содержимого, а не от метаданных. В результате для одного бинарника может существовать несколько .drv файлов с разными хэшами, что объясняет парадокс: кэш NixOS указывает на один .drv, а nix derivation show находит другой, но оба ведут к одному и тому же выходному пути.

• Проблема deriver в Nix — это давняя проблема, которая не решается, потому что она не может обеспечить трассируемость от вывода к исходному выражению, что и было первоначальной целью.
• Пользователи сталкиваются с путаницей, когда кэш бинарников не совпадает с локальной оценкой, что приводит к непониманию и неэффективному использованию кэша.
• Появление CA-derivations и фиксированных выводов (fixed-output derivations) усугубляет ситуацию, делая проблему более заметной, но не решает ее.
• Сообщество обсуждает, что необходимо переписать Nix с нуля, чтобы устранить такие архитектурные проблемы, включая проблему deriver.
• Некоторые участники обсуждения подчеркивают, что Guix может быть альтернативой, но его недостаток в количестве пакетов делает его менее привлекательным.

Представлен gem.coop — новый сервер для хранения гемов в экосистеме Ruby, созданный бывшими сопровождающими RubyGems.org. Он предлагает быстрый и простой хостинг, совместимый с Bundler, но оптимизированный для будущего. Все гемы с RubyGems.org доступны в реальном времени, а для использования достаточно заменить источник в Gemfile на https://gem.coop.

Управление проектом организовано по модели Homebrew при поддержке Mike McQuaid, с открытым участием сообщества. Цели — прозрачность, устойчивость и безопасность при общедоступном хостинге. Запуск включает поддержку установки публичных гемов, с планами по дальнейшему улучшению.

• Создана новая альтернативная платформа для пакетов Ruby (gem.coop) из-за конфликта между прежними сопровождающими RubyGems и Ruby Central.
• Обсуждаются технические и организационные аспекты форка: финансирование, необходимость подписи кода, доверие к сопровождающим и проблемы с доступностью из-за домена .coop.
• Часть сообщества поддерживает форк как способ сохранить независимость, другие видят в нём ненужное дробление экосистемы.
• Поднимаются вопросы о мотивах создания форка: является ли это реакцией на политические разногласия или стремлением улучшить техническую инфраструктуру.
• Проводятся параллели с другими инцидентами в open-source (например, переход с Freenode на Libera Chat).

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-компаниями как основного механизма обнаружения угроз, который может быть эффективнее индивидуальных задержек.
• Подчёркивается, что семантическое версионирование не всегда идеально соблюдается, и даже минорные обновления могут ломать совместимость, создавая риски при автоматическом обновлении.

О нет, снова... Размышления об атаках на цепочку поставок NPM

Я долго откладывал эту статью — более года — но, как мы видим на этой неделе, пришло время снять покровы и сказать вслух:

В 2025 году Microsoft следует считать «плохим игроком» и угрозой для всех компаний, разрабатывающих программное обеспечение.

Конечно, если вы достаточно взрослые, чтобы помнить — это не первый раз...

Время — плоский круг

Мы снова здесь — в 2025 году Microsoft настолько всё испортили, что создали ещё больший риск, чем в 2000-х с их браузером, просто ничего не делая.

Изначально я начал писать этот пост во время инцидента с xz — изощрённой и долгосрочной попытки взять под контроль библиотеку, используемую в менеджерах пакетов большинства дистрибутивов Linux.

С тех пор произошло множество инцидентов, и конкретно NPM стал крупнейшим и самым простым способом распространения вредоносного ПО. Сначала большинство атак было направлено на кражу криптовалюты (поскольку техбро одержимы магическими электрическими деньгами и являются лёгкой добычей). Но теперь эти атаки на цепочку поставок нацелены на более критичные вещи, такие как токены и ключи доступа maintainers пакетов, как видно из инцидента с NX и теперь несколькими зависимостями, ежедневно используемыми тысячами разработчиков.

Опять же... это ничего нового в мире NPM.

Но так быть не должно было...

Мы прошли долгий путь, но никуда не ушли

У меня долгая история с NodeJS — примерно в 2010 году я начал работать над стартапом, и это было до того, как npm вообще появился.

В туманные дни 1990-х большинство проблем безопасности JavaScript не сильно касались бэкенда: это в основном была область Perl, PHP, Python и Java.

Однако веб был совсем другой историей.

В самые ранние дни Всемирной паутины был только один основной браузер, который все использовали: Netscape Navigator. Выпущенный в 1994 году, он был не просто браузером: на протяжении своей жизни он имел различные воплощения встроенного почтового клиента, календаря, HTML-редактора с FTP-браузером, а с плагинами мог воспроизводить медиафайлы, такие как Realplayer и MP3 (что я помню при его запуске), а также флеш-фильмы и игры. Именно здесь родился JavaScript.

Многие ранние сайты того времени были статичными — популярные инструменты для создания сайтов включали HotDog или Блокнот. Никаких навороченных IDE или фреймворков, только текстовый редактор, браузер и alert() для отладки.

Microsoft также вошла в игру с Internet Explorer — включённым в раннее DLC для Windows под названием «Plus! For Windows 95». В конечном итоге он стал программным обеспечением, на которое Microsoft поставила всю свою корпоративную стратегию (во многом как сегодня с ИИ).

Internet Explorer был встроен в каждый аспект Windows — сначала в 1995 году с Active Desktop, что продолжалось вплоть до Windows XP. С ним можно было встраивать фрейм на рабочий стол, а также документы Rich Text или электронные таблицы Excel. Он также был раздутым и багнутым — и с этим представлял две проблемы: огромный риск безопасности и обвинения в монополизации рынка браузеров.

Закон жёстко настиг Microsoft, и в 2001 году она проиграла — Microsoft было приказано разбить компанию, но апелляция отменила это решение.

• Участники критикуют экосистему npm за уязвимости в цепочке поставок и отсутствие безопасности по умолчанию, сравнивая её с другими менеджерами пакетов.
• Обсуждается роль крупных компаний (в частности, Microsoft как владельца npm) в решении проблем безопасности и их ответственность за состояние экосистемы.
• Предлагаются конкретные меры: обязательная 2FA, подписывание кода, политика задержки обновлений (cooldown), переход на альтернативы (pnpm), сканирование пакетов.
• Поднимается проблема эксплуатации труда добровольцев в open-source и недостаточного вклада коммерческих организаций в проекты, которые они используют.
• Отмечается, что культура JavaScript-разработки чрезмерно зависит от большого количества зависимостей, что увеличивает поверхность атаки.
• Указывается на необходимость более строгого контроля зависимостей, включая проверку кода и фиксирование версий (pinning).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.