• Обсуждение вокруг пакета golang.org/x/tools/gopls и его влияния на разработку, включая предложение использовать Go вместо JavaScript, вызвало споры о целесообразности и практичности такого подхода.
• Участники обсуждали, что вместо того, чтобы писать на Go, лучше позволить импортировать .go файлы, что более идиоматично для JS бандлеров.
• Поднялся вопрос о том, что клиентский код не должен диктовать бизнес-логику, и что стоит быть осторожным с подобными техниками.
• Была отмечена важность такого подхода для обучения и вдохновения новичков в области WASM и Go.
• Также было отмечено, что это может быть полезно для оффлайн-функциональности и как фоллбек, если API недоступен.
• В конце концов, обсуждение свелось к тому, что это может быть полезно для обучения и вдохновения новичков в области WASM и Go.

GitHub добавил встроенные CSS-функции, упрощающие стилизацию. Теперь можно писать @function square(n) { return: calc(n * n); } и использовать как width: square(10px); — это компилируется в width: 100px;. Функции поддерживают условные операторы, вроде if (condition) { … } else { … }, математические операции и даже переменные. Это похоже на препроцессинг, но встроенное в браузер. Документация уже обновлена с примерами. Пользователи в восторге, особенно от интеграции с существующими проектами, упрощающей миграцию.

• Обсуждение в основном вращается вокруг новой возможности CSS @function, где участники обсуждают её влияние на производительность, стандартизацию и будущее веб-разработки.
• Некоторые участники выражают обеспокоенность по поводу того, что CSS становится всё более сложным и мощным, что может привести к проблемам с обратной совместимостью и увеличению сложности веб-разработки.
• Обсуждается, что новые функции CSS, такие как @function, могут потенциально заменить некоторые существующие инструменты и техники, такие как препроцессоры и фреймворки.
• Участники также обсуждают, насколько необходимо иметь эту функцию в виде npm пакета, и если это будет способствовать или препятствовать распространению и использованию этой функции.

Инструмент mise теперь поддерживает задачи в монорепозиториях, позволяя запускать команды в нескольких проектах одновременно. Это упрощает управление зависимостями и скриптами, особенно при работе с большими кодовыми базами. Например, можно выполнить mise run build для сборки всех проектов или mise run test для запуска тестов.

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

• Пользователи высоко оценивают mise за универсальность в управлении версиями языков (Node, Python, Rust, Go) и инструментами в одном конфиге, упрощающую onboarding в проектах.
• Отмечается удобство встроенного раннера задач, который заменяет Makefile/Just и работает в монорепозиториях, обеспечивая единый интерфейс для задач независимо от языка.
• Высказываются опасения по поводу сложности PATH-менеджмента и возможного чрезмерного расширения функциональности (например, отсутствие кэширования задач и поддержки Windows).
• Некоторые пользователи сравнивают mise с более сложными системами (Bazel, Nix), отмечая его как более простую альтернативу с низким порогом входа.
• Обсуждаются интеграции с другими инструментами (uv, moon, turborepo) и необходимость улучшения документации, особенно для новичков.

• Обсуждаются новые функции Claude Code: расширение для VS Code, команда /rewind для отмены изменений, переработанный интерфейс и управление контекстом.
• Пользователи сравнивают Claude Code с конкурентами (Cursor, Aider, Goose), отмечая его преимущества и недостатки, такие как интеграция с инструментами и эргономика.
• Поднимаются вопросы о конфиденциальности данных, потреблении ресурсов (ОЗУ) и проблемах с UX/UI в новом расширении VS Code.
• Обсуждаются технические аспекты: работа с CJK-вводом, управление памятью, поддержка MCP, а также использование тегов и магических команд в промптах.
• Высказываются предложения по улучшению: индикация функции в diff, отображение оставшегося контекста, отмена выполнения промпта и улучшение команды /resume.

Автор успешно удалил около 120 неиспользуемых зависимостей в Nx-монополии, сократив время установки на минуту и уменьшив количество уязвимостей. Для этого он использовал инструмент Knip вместо устаревшего depcheck, так как он лучше работает с современными монополями и анализирует импорты и конфиги. Knip выдал список потенциально ненужных пакетов, но около 40% из них оказались ложными срабатываниями — например, зависимости использовались в скриптах, конфигах Jest или CSS.

Процесс включал удаление кандидатов, последующую проверку сборки, тестов и запуска приложений, а затем восстановление пакетов, которые оказались нужны, с добавлением их в ignore-лист Knip. Автор настроил конфиг под монополию, игнорируя специфичные для проектов ложные срабатывания. Изменения были мержены одной партией в тихое время с предварительным деплоем в preview-ветку для проверки. В будущем планируется интегрировать Knip в CI для предотвращения накопления мусора.

• Обсуждаются причины накопления неиспользуемых зависимостей: невнимательность разработчиков, множественные рефакторинги, устаревшие библиотеки в монорепозиториях и автоматическое добавление пакетов без контроля.
• Участники отмечают, что инструменты вроде Knip помогают выявлять мертвые зависимости и файлы, но не оценивают качество кода, и окончательное решение остается за человеком.
• Экосистема и практики разработки (например, pip freeze или npm install без проверки) поощряют накопление лишних пакетов.
• В больших и старых проектах, особенно с микросервисами и смешанными стеками, "хлам" накапливается быстро из-за миграций и отсутствия регулярной очистки.
• Некоторые видят в постоянной борьбе с кликбейтом и переименованиях заголовков раздражающий и непродуктивный аспект обсуждений.

Обнаружена первая вредоносная реализация MCP-сервера в дикой природе — пакет postmark-mcp, который с версии 1.0.16 тайно копирует все отправляемые письма на внешний сервер злоумышленника. Пакет скачивался 1500 раз в неделю и интегрировался в рабочие процессы разработчиков, получая полный доступ к почтовым данным, включая сбросы паролей, конфиденциальные документы и финансовые отчеты.

Атака основана на имперсонации: злоумышленник скопировал код официального репозитория Postmark, добавил скрытую строку BCC и опубликовал под тем же именем в npm. Уязвимость оставалась незамеченной, так как MCP-серверы работают вне периметра безопасности, обходя системы контроля DLP и инвентаризации активов. Это демонстрирует растущие риски supply-chain-атак через инструменты ИИ, которые получают привилегии без должной проверки.

• Участники обсуждают риски использования сторонних пакетов и инструментов, проводя параллели с историческими проблемами безопасности, такими как уязвимости в почтовых клиентах или SQL-инъекции.
• Высказываются предположения, что инцидент с пакетом postmark-mcp мог быть не злонамеренной атакой, а случайной ошибкой разработчика, оставившего отладочный код.
• Поднимается вопрос о доверии к ИИ-инструментам и MCP-серверам, которые получают чрезмерные права доступа к данным без должного контроля со стороны пользователей.
• Критикуется практика публикации статей, обработанных ИИ, что затрудняет восприятие и проверку фактов, а также общая культура безопасности в разработке, где скорость часто важнее надежности.
• Обсуждается ответственность платформ (например, npm) и необходимость более строгих правил для предотвращения подмены пакетов и supply chain-атак.

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

Атака на поставки @ctrl/tinycolor: разбор инцидента

Злоумышленник добавил вредоносный workflow в GitHub Actions общего репозитория и похитил npm-токен с правами публикации. С помощью этого токена были опубликованы вредоносные версии 20 пакетов, включая @ctrl/tinycolor.

Мой аккаунт GitHub и репозиторий @ctrl/tinycolor не были скомпрометированы напрямую. Не использовался фишинг, на моём компьютере не устанавливались вредоносные пакеты. GitHub и npm оперативно отреагировали, удалив зловредные версии. Я выпустил чистые версии пакетов для очистки кэшей.

Как это произошло

Раньше я участвовал в проекте angulartics2 — общем репозитории, где у нескольких человек были права администратора. Там остался секрет GitHub Actions — npm-токен с широкими правами на публикацию.

Злоумышленник принудительно отправил ветку Shai-Hulud в angulartics2 с вредоносным workflow. Workflow запустился сразу после отправки (без проверки, так как у collaborator были права администратора) и украл npm-токен. С помощью украденного токена атакующий опубликовал вредоносные версии 20 пакетов.

Планы на будущее

Сейчас я использую semantic-release с GitHub Actions для публикации. Моя цель — перейти на Trusted Publishing (OIDC) в npm, чтобы полностью отказаться от статических токенов. Однако интеграция с semantic-release ещё в разработке.

Для небольших пакетов я продолжу использовать semantic-release, но с ужесточённым контролем: никаких новых участников, отдельные npm-токены с правами только на публикацию конкретного пакета.

Я планирую и дальше использовать pnpm, который блокирует неавторизованные postinstall-скрипты, и изучу новую настройку minimumReleaseAge.

Пожелания к системе публикации

В идеале хотелось бы иметь в npm единый переключатель для принудительного использования Trusted Publishing (OIDC) для всех моих пакетов. Такой же переключатель блокировал бы любые релизы без provenance, обеспечивая безопасность на уровне аккаунта. Также хотелось бы иметь встроенную поддержку semantic-release с OIDC и provenance, чтобы статические токены больше не требовались.

Кроме того, было бы удобно иметь безопасный вариант публикации с подтверждением человека прямо в интерфейсе GitHub: защищённый workflow_dispatch, использующий 2FA GitHub для удовлетворения требованиям двухфакторной аутентификации без необходимости публиковать со своего компьютера.

• Предлагается использовать ручные релизы и многоэтапные проверки для публикации пакетов вместо полной автоматизации CI/CD.
• Обсуждаются недостатки долгоживущих токенов и предлагается использовать Trusted Publishing с короткоживущими токенами или OIDC.
• Поднимается вопрос о необходимости встроенной MFA (двухфакторной аутентификации) для подтверждения публикации в CI-системах.
• Предлагается разделить процесс на загрузку пакета и его публикацию для пользователей, чтобы повысить контроль.
• Обсуждается идея использования подписей нескольких авторов или проверки подписей коммитов для обеспечения безопасности.
• Отмечается сложность настройки безопасных машинно-машинных потоков (OIDC) и необходимость более простых решений.
• Упоминается, что многие разработчики игнорируют вопросы безопасности до момента взлома и необходимы системные изменения.

О нет, снова... Размышления об атаках на цепочку поставок 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).
• Некоторые участники считают, что фундаментальные изменения в экосистеме маловероятны, и рекомендуют индивидуальные меры защиты.

Компрометация пакетов ctrl/tinycolor и 40+ других в NPM

Популярный пакет @ctrl/tinycolor с более чем 2 млн загрузок в неделю был скомпрометирован вместе с 40+ другими пакетами в результате сложной атаки на цепочку поставок. Вредоносное ПО самораспространяется по пакетам maintainer'ов, собирает учетные данные AWS/GCP/Azure с помощью TruffleHog и создает бэкдоры через GitHub Actions.

Технический анализ

Атака реализуется через многоступенчатую цепочку, использующую Node.js process.env для доступа к учетным данным. Основной элемент — файл bundle.js (~3.6 МБ), который выполняется асинхронно во время npm install.

Механизм самораспространения
Вредоносное ПО через функцию NpmModule.updatePackage запрашивает API реестра NPM для получения до 20 пакетов maintainer'а и принудительно публикует обновления, создавая каскадный эффект компрометации.

Сбор учетных данных
Используются инструменты вроде TruffleHog для сканирования файловой системы на наличие секретов. Целевые учетные данные включают:

• Токены доступа GitHub
• Ключи доступа AWS
• Учетные данные Google Cloud Platform

• Пользователи выражают обеспокоенность невозможностью аудита всех зависимостей и их уязвимостью к атакам в npm.
• Критикуется архитектура npm, в частности выполнение postinstall-скриптов по умолчанию, в отличие от других менеджеров пакетов.
• Предлагаются решения: игнорирование скриптов в настройках, песочница (bubblewrap), использование подписей кода и каррированных пакетов.
• Указывается на системную проблему экосистемы JS: огромное количество мелких зависимостей и отсутствие сильной стандартной библиотеки.
• Обсуждается масштаб атаки (180+ пакетов) и её возможная связь с государственными акторами.
• Поднимается вопрос уязвимости других экосистем (PyPI) и необходимости обязательной 2FA и подписи артефактов.
• Высказываются радикальные предложения по замене npm или созданию безопасного форка/дистрибутива пакетов.

• Обсуждаются строгие правила CRAN для R-пакетов, требующие обратной совместимости и тестирования всех зависимых пакетов при обновлении, что сравнивают с монорепозиторием.
• Поднимаются проблемы других экосистем (Python, npm), где распространены ломающие изменения и конфликты зависимостей, и отмечается стабильность R.
• Участники спорят о практичности подхода CRAN: одни видят в нём бремя для разработчиков, другие — выгоду для научной воспроизводимости и пользователей.
• Предлагаются альтернативы и обходные пути, такие как полное форкирование, версионирование API или контейнеризация.
• Отмечается уникальная философия R-сообщества, ориентированная на статистиков, а не на разработчиков, что объясняет такие жёсткие требования.

• Пользователи высоко оценили GPT-5-Codex за умение работать с длинным контекстом, качественное исследование кода и завершение задач без "бросания на полпути", в отличие от Gemini и Claude Code.
• Основные жалобы на Codex касаются нестабильности сервиса (частые простои), высокой скорости расходования кредитов и автоматического списания средств при превышении лимита плана Pro.
• Многие сравнивают Codex с Claude Code, отмечая, что после обновления Codex стал значительно эффективнее, особенно в рефакторинге, хотя иногда может проявлять "лень" и требовать подтверждения для продолжения сложных задач.
• Обсуждается проблема несоответствия форматирования (Codex использует пробелы вместо табов) и отсутствие поддержки пользовательских контейнеров.
• Новая модель GPT-5-Codex, оптимизированная для кодинга, стала доступна в CLI и облачных продуктах OpenAI, но пока не в API; она обещает улучшенный код-ревью и возможность работать до 7 часов.
• Некоторые пользователи столкнулись с замедленной работой модели и проблемами скорости, не видя существенной разницы между режимами medium и high.
• Важным фактором для многих остается конфиденциальность, и в этом отношении Cursor с его "режимом приватности" сохраняет преимущество перед Codex.
• В обсуждении упоминается добавление поддержки MCP (Model Context Protocol) и необходимость ручного обновления CLI через NPM для доступа к новым функциям.
• Отмечается, что JetBrains с бэкендом на GPT-5 предлагает подписку за $30/мес, но квоты сгорают очень быстро, что вызывает вопросы о долгосрочной ценовой политике OpenAI.

• Новый GPT-5-Codex имеет вдвое меньший размер промпта (10 КБ против 23 КБ) и демонстрирует схожую с GPT-5 производительность на SWE-bench, но значительно лучше справляется с рефакторингом (51.3% против 33.9%).
• Пользователи отмечают резкое улучшение качества Codex CLI по сравнению с предыдущими версиями и конкурентом Claude Code, который, по их мнению, стал хуже и имеет более низкие лимиты использования.
• Многие пользователи переходят с Claude Code на Codex, мотивируя это большей скоростью, щедрыми лимитами использования, включенными в подписку ChatGPT Pro, и меньшей склонностью модели к "фейковым" решениям.
• Ключевые улучшения UX: модель стала надежнее использовать интерфейс выполнения задач (Task Completion), лучше комментирует код при ревью и генерирует меньше лишних токенов для простых задач.
• Некоторые пользователи сталкиваются с проблемами: крайне низкая скорость работы модели в первые дни после релиза, сложности с установкой (npm-ошибки) и отсутствие режима, аналогичного "normal mode" в Claude.
• Появилась интеграция Codex CLI с планом подписки ChatGPT (около месяца назад), что делает его более доступным, однако поддержки API для GPT-5-Codex пока нет, но обещана в будущем.
• Обсуждаются workflow-проблемы: отсутствие промежуточного режима между полной автономией и ручным копированием, плохая обработка перемещения файлов, необходимость вручную одобрять опасные команды.
• Конкуренция смещается с raw-качества моделей на качество интеграции в IDE и workflow (терминал, GitHub, мобильное приложение), создавая эффект lock-in.
• Пользователи рекомендуют стратегию работы: сначала заставлять модель составлять план и утверждать его, а лишь потом приступать к реализации, чтобы избежать нежелательных действий.

• На этой неделе после атаки на npm целью стал crates.io.
• Рассылается письмо «Инцидент безопасности: взлом инфраструктуры».
• Просят перейти по ссылке и войти через «внутренний SSO» — это фейк.
• Сайт копирует GitHub-авторизацию, крадёт токены.
• Подделка заметна по домену, отсутствию HTTPS и странному URL.
• Настоящий crates.io никогда не просит войти через сторонние формы.
• Получили письмо — удалите, не кликайте; включите 2FA и проверьте токены.

• Фишинг снова в тренде: мошенники массово атакуют разработчиков через «сломанные» пакеты (npm, crates.io), подделывают e-mail от PayPal и GitHub.
• Самые опасные письма подписываются реальным доменом (paypal.com, github.rustfoundation.dev) и ведут на поддельный «внутренний» логин; звонки «от банка» тоже подменяют номер.
• Правило «ноль доверия»: не кликайте, не звоните по указанным ссылкам/номерам; заходите на сайт вручную или набираете официальный номер из надежного источника.
• Даже опытные разработчики чуть не ведутся: письмо выглядит срочным, без опечаток, с корректным логотипом и SSL, но просит «подтвердить» учётку на стороннем домене.
• Защита: включайте passkey / 2FA, не вводите пароль на незнакомых доменах, после любого изменения безопасности временно блокируйте публикацию пакетов.

Как устроен bun install

• Один бинарник — весь менеджер зависимостей живёт внутри Bun, нет внешних вызовов к npm, yarn, node-gyp.
• Сишный движок — парсинг package.json, yarn.lock, node_modules происходит на Zig, без JS-оверхеда.
• HTTP-пул + кэш — 50–100 параллельных потоков, кэш на диске + SQLite-индекс, повторный install — <100 мс.
• Symlink-ферма — модули не копируются, а hard-link’ются из глобального кэша; экономия 70 % диска.
• Муравьиный алгоритм — сначала скачиваются «листья» дерева зависимостей, потом родители; сеть греется максимально.
• Платформенные пакеты — если в lock-файле есть запись под Linux, macOS и Windows, скачиваются сразу три архива и раскладываются в node_modules/.cache, при запуске выбирается нужный.
• postinstall без shell — скрипты запускаются встроенным JS-движком, нет overhead’а на spawn bash/cmd.
• Проверка целостности — каждый tarball сверяется по SHA256 из lock-файла, кэш защищён от подмены.
• Мониторинг прогресса — терминал обновляется раз в 16 мс, рисуется ASCII-полоса и счётчик «пакетов/сек».
• Фоллбек к npm — если пакет не найден в официальном реестре, Bun автоматом лезет в npm и кладёт tarball в кэш, пользователь не замечает разницы.

• Пользователи обсуждают статью о внутреннем устройстве и производительности менеджера пакетов Bun.
• Многие хвалят скорость и простоту Bun, но отмечают проблемы совместимости с Node.js и стабильностью.
• Часть комментаторов сомневается в практической пользе высокой скорости установки пакетов и считает переход с Node.js рискованным.
• Упоминаются альтернативы — Deno, pnpm, npm — и сравнение с ними по скорости и надёжности.
• Некоторые считают, что Bun не предлагает «убийственных» фич, чтобы оправдать переход с зрелой экосистемы Node.js.

Коротко: в NPM проникли популярные пакеты (colors, debug и др.) через фишинг письмо «смени 2FA». Вредоносный код подменял адреса криптокошельков.
Почему это мелко: библиотеки используются в CLI-утилитах, а не в Web3; украденные API-ключи или майнеры были бы катастрофой.
Вывод: любая зависимость может быть трояном, но проверять всё дерево пакетов никто не успевает — надо успевать релизить.

• Атака на NX через NPM показала, что даже популярные плагины могут стать вектором для кражи creds и API-кейсов.
• Участники сходятся: «всё дерево зависимостей NPM по умолчанию доверяет всем», а ручная проверка каждой мелкой библиотеки невозможна при скорости релизов.
• Многие выжили лишь благодаря «отложенным обновлениям», изоляции в контейнерах или отказу от экосистемы Node/NPM целиком.
• Фишинг на домене npm.help подтвердил, что даже IT-специалисты не всегда замечают поддельные TLD; предлагают белые списки ссылок и DMARC-индикаторы в клиентах.
• Утверждение «мы просто не заметили более продвинутые атаки» звучит всё чаще: Jia Tan 3.0, по мнению комментаторов, уже где-то в supply-chain.

• В npm-пакетах DuckDB версий 1.3.3 и 1.29.2 обнаружена вредоносная вставка.
• При установке пакета запускается пост-скрипт, который скачивает и исполняет сторонний исполняемый файл, собирая сведения о системе и отправляя их на сторонний сервер.
• Проблемные версии удалены из реестра npm; рекомендовано немедленно удалить их из проектов и перегенерировать все ключи/токены.

• Атака на NPM-пакеты DuckDB — результат обычного фишинга: злоумышленник подменил сайт, украл 2FA и сразу опубликовал вредоносные версии.
• Пострадали 4 пакета; вредоносный код вмешивался в криптотранзакции, но денег не украл.
• Уязвимость — человеческий фактор: даже технические мейнтейнеры кликают по ссылкам в «срочных» письмах.
• Обсуждение сводится к тезису: подписывать артефакты, использовать пасскеи/HSM, вводить «заморозку» публикации после смены 2FA и требовать ≥2 подписи мейнтейнеров.
• NPM-сообщество считает, что критическая инфраструктура (NPM, PyPI, Maven) должна быть защищена строже, чем обычные сервисы.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

Пакетные менеджеры — зло

Пакетные менеджеры автоматизируют ад зависимостей: скачивают пакет → его зависимости → зависимости зависимостей… и ты в аду. Вручную хотя бы думаешь: «а надо ли?»

Большинство языков не знают, что такое «пакет», поэтому менеджер сам его придумывает. В итоге появляются «менеджеры менеджеров» (npm, yarn, pnpm…).

Языки с толстой стандартной библиотекой (Go, Odin) откладывают ад: 90 % задач решаются без сторонних пакетов.

Каждая зависимость — это долг: баги, security, поддержка. Мы взяли SDL2 — и год убили на чужие баги; проще написать своё, чем обновиться до SDL3.

Доверие к случайному коду из интернета — социальная болезнь программистов.

• Критика менеджеров пакетов сводится к тому, что они «автоматизируют ад зависимостей», скрывая от разработчика реальные издержки и риски.
• Автор предлагает вручную копировать и фиксировать нужные версии библиотек, чтобы осознанно контролировать, что именно попадает в проект.
• Оппоненты считают идею регрессом: ручное управление не масштабируется, тормозит разработку и не решает проблему транзитивных зависимостей.
• Поддержка Cargo, npm и прочих инструментов признаётся необходимой, но критикуется культура «микро-зависимостей» и отсутствие вендоринга.
• Компромисс видят в строгом вендоринге (Google), фиксации версий, feature-gates и использовании «batteries-included» стандартных библиотек (Go).

FuckUpMySite — преврати любой сайт в хаос.

• Деструкция: 0 %
• Лозунг: fuckfuckfuckfuckupupupupmymymymysitesitesitesite
• Девиз: «Некоторые просто хотят смотреть, как горит веб».

Попробуй на: Sentry.io, Hacker News, Apple, Stack Overflow
Кнопка: «FUCK THIS SITE UP»

😈 Настройки хаоса

(3 из 6 активны)

• 🔥 Пылающий курсор — курсор поджигает страницу
• 🤪 Comic Sans всё — весь текст Comic Sans
• 👻 Фальшивые курсоры — множество поддельных теней
• 🪰 Назойливая муха — жужжит по экрану
• 🏃 Убегающие кнопки — прячутся от мыши
• 🔨 Попап-лопатка — ложные окна, которые нужно закрывать

Не все сайты дружат с хаосом. Нашёл баг? Напиши в Twitter.

• Участники обсуждают сайт-шутку, который «ломает» любую страницу: Comic Sans, ползающие жуки, огонь и т.д.
• Браузеры (Chrome, Firefox, Safari) блокируют его как «опасный», что вызывает смех — предупреждение идеально вписывается в дух проекта.
• Некоторые сравнивают его с Katamari Hack, Desktop Destroyer, netdisaster и старыми оверлеями 90-х.
• Работает не везде: падает на Whitehouse.gov, opennet.ru, сайтах с Anubis, а также на самом себе.
• Люди делятся ссылками на «испорченные» версии Fox News, Apple и др.; кто-то просит npm-пакет для розыгрыша.

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 для низкокритичных задач, а критичный код вендорится и аудируется.

Как создать инструкцию по установке MCP-сервера

1. Определите тип сервера

   • stdio – локальный процесс.
   • sse – удалённый HTTP-эндпоинт.

2. Соберите метаданные

   • Название, описание, автора, ссылку на репозиторий.
   • Требования: Node.js, Python, Docker и т.д.
   • Порт (для SSE), путь к исполняемому файлу (для stdio).

3. Сформируйте claude_desktop_config.json
   Пример stdio:

   {
     "mcpServers": {
       "my-server": {
         "command": "node",
         "args": ["build/index.js"],
         "env": { "API_KEY": "xxx" }
       }
     }
   }
   

   Пример SSE:

   {
     "mcpServers": {
       "my-server": {
         "url": "http://localhost:3000/sse",
         "headers": { "Authorization": "Bearer xxx" }
       }
     }
   }
   

4. Сгенерируйте инструкцию

   • Установите зависимости (npm i, pip install -r requirements.txt).
   • Скопируйте claude_desktop_config.json в %APPDATA%\Claude\ (Win) или ~/Library/Application Support/Claude/ (macOS).
   • Перезапустите Claude Desktop.

5. Проверьте работу
   Откройте Claude → шестерёнка → Developer → MCP → убедитесь, что сервер “Connected”.

6. Опубликуйте
   Добавьте README.md с шагами выше и примером конфига.

• Пользователи хотят не просто «забронировать», а исследовать: «покажи самые дёшевые окна в Токио за 3 месяца».
• Все сходятся, что полностью автономное бронирование пока ненадёжно: доверие к ИИ низкое, цены скачут, а условия договора надо принимать вручную.
• MCP-серверы рассматриваются как новая «AI-API» — удобно для агентов, но бизнес может быстро закрыть доступ, если это ударит по рекламе и контролю.
• Kiwi и прочие агрегаторы могут зарабатывать на самой продаже билетов и страховках, а не на рекламе, но риски покупки у посредников остаются.
• Пока что MCP-инструменты лучше работают как «умный поиск с последующим подтверждением человека», а не как полностью автономный консьерж.

Критическая уязвимость в NX
NX (Nrwl) скомпрометирован: злоумышленники внедрили вредоносный код, крадущий кошельки и учётные данные.

• Что случилось: в пакетах @nx/nx-linux-x64-gnu, @nx/nx-linux-x64-musl, @nx/nx-win32-x64-msvc обнаружен backdoor.
• Как работает: при установке пакета запускается скрипт, который крадёт файлы .env, wallet.dat, id_rsa и отправляет их на сервер злоумышленников.
• Кто под угрозой: все, кто установил заражённые версии с 2024-06-01 по 2024-06-05.
• Что делать:
  1. Проверить версию NX: nx --version.
  2. Обновиться до последней версии (≥19.1.1).
  3. Проверить проект на наличие подозрительных скриптов в node_modules/.bin.
  4. Сменить все пароли и ключи, хранившиеся в проекте.

Semgrep уже выпустил правило для обнаружения вредоносного кода:

semgrep --config=auto .

• Компрометация npm-токена позволила злоумышленнику встроить вредоносный post-install-скрипт в популярные пакеты Nx.
• Скрипт проверяет наличие Claude Code / Gemini CLI и использует LLM для поиска секретов, обходя статический анализ.
• Участники советуют отключать npm-скрипты (ignore-scripts true), использовать pnpm/bun, изолировать установку в контейнеры/VM и минимизировать зависимости.
• Подчёркивается, что AI-агенты, запускаемые без песочницы, становятся мощным вектором атаки.

Суть проблемы
В 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», а операционные системы всё ещё позволяют приложениям свободно читать весь диск.

async-server — это CLI-утилита, объединяющая Claude Code, Linear и GitHub PR.
Она позволяет:

• Планировать задачи прямо в терминале (как в Linear).
• Писать код с помощью Claude Code: создавать ветки, коммиты, PR.
• Ревьюить изменения и мержить без выхода из консоли.

Установка:

npm i -g async-server
async-server init

Команды:

• async task "добавить логин" – новая задача.
• async code – Claude генерирует код.
• async pr – создаёт PR и связывает с задачей.

Полностью асинхронный workflow: задачи, код, ревью — всё в одном потоке.

• Пользователи хвалят темную тему и концепцию, но сомневаются в необходимости платить GCP за каждое взаимодействие и просят локальный режим.
• Критика: не хватает полноценного тестирования (сборка/запуск кода), а упоминание Linear в заголовке кажется лишним.
• Автор подтверждает: сейчас большая часть выполняется в облаке, но команда работает над локальной версией и улучшенным тестированием изменений.

DeepWiki — сервис от создателей Devin, который мгновенно превращает любой GitHub-репозиторий в интерактивную вики.
Просто замените github.com на deepwiki.com и задавайте вопросы без чтения кода.

8 практических приёмов

1. Разведка репозитория
   За 2 минуты получаю архитектуру, ключевые модули и точки расширения.

2. Контекст для агентов
   Копирую сводку в Claude/Cursor, чтобы сразу писать релевантный код.

3. Быстрый старт
   Генерирую README-инструкции по запуску без ручного изучения docker-compose.yml.

4. Поиск «кухонных» деталей
   Уточняю, где хранятся env-переменные, какие скрипты npm run доступны и т.д.

5. Сравнение форков
   Загружаю две вики и спрашиваю: «Что добавлено в форке X по сравнению с оригиналом?»

6. Онбординг новичков
   Раздаю ссылку на вики вместо 30-минутных экскурсий по коду.

7. Проверка зависимостей
   Запрашиваю список уязвимых пакетов и актуальные версии.

8. Документация API
   Прошу сгенерировать примеры вызовов REST-endpoints прямо из кода.

Ограничения

• Публичные репозитории работают сразу.
• Приватные — через GitHub OAuth с нужными правами.
• Нет поддержки SVN и Mercurial.

DeepWiki экономит часы при изучении чужого кода и делает LLM-агентов значительно точнее.

• DeepWiki вызывает противоречивые ощущения: кто-то хвалит автодиаграммы и «глубокие» ответы, кто-то ругает за неточности и «AI-slop».
• Пользователи LibreOffice, PureLB и других проектов жалуются на ложную документацию и баг-репорты, которые тратят время мейнтейнеров.
• Некоторые считают, что диаграммы слишком абстрактны и не привязаны к реальному коду.
• Появились попытки сделать open-source/локальные аналоги, но официального способа «выключить» DeepWiki для своего репозитория пока нет.

Node.js v22.18.0 LTS
31 июля 2025

Главное

• TypeScript без конфигурации
  .ts файлы запускаются напрямую:

  echo 'const foo: string = "World"; console.log(`Hello ${foo}!`);' > file.ts
  node file.ts   # → Hello World!
  

  Ограничения описаны здесь. Отключить: --no-experimental-strip-types.

Ещё важное

• amaro обновлён до 1.1.0
• import.meta.main в ESM
• fs лучше справляется с всплесками событий через AsyncIterator
• permission передаёт флаги модели разрешений при spawn
• sqlite поддерживает readBigInts на уровне соединения
• url добавлен fileURLToPathBuffer
• watch новый флаг --watch-kill-signal
• Worker стал асинхронно disposable

Другое

• npm 10.9.3, sqlite 3.50.2, обновления minimatch, acorn, googletest
• мелкие исправления в crypto, build, assert и др.

• Node.js теперь умеет запускать .ts-файлы «из коробки», вырезая типы без транспиляции, но поддерживает лишь подмножество TS (без enum и т.п.).
• Новая возможность не распространяется на node_modules, что вызывает вопросы о библиотеках и приватных пакетах.
• Многие радуются упрощённому DX, но часть пользователей уже сталкивается с ошибками обновления из-за ограниченного набора фич.
• Критики считают, что Bun и Deno давно решают эти задачи лучше и быстрее, однако Node остаётся «де-факто» стандартом.
• Итог: шаг вперёд для Node, но полноценная замена tsc/Bun пока невозможна; выбор рантайма по-прежнему зависит от проекта.

IPv4 Games
Justine Tunney, 16 авг 2025

Сервис ipv4.games предлагает «захватывать» IP-адреса: достаточно установить TCP-соединение с виртуальной машиной Google. Игрок femboy.cat из Европы уже «забрал» 20 млн адресов (≈ 9 % IPv4-узлов по Censys). Как он это делает? Кто станет североамериканским конкурентом?

• «ipv4.games» считает IP «захваченным», если он хоть раз загрузил скрытый 1×1-пиксельный трекер; никаких проверок владения не требуется.
• 9 % — это 20 млн из ~220 млн IP, которые Censys видит с открытыми портами, а не из всего адресного пространства IPv4.
• Лидеры просто встроили трекер в популярные сайты, рекламу или npm-пакеты, заставляя посетителей «захватывать» IP за них.
• Версии о спуфинге X-Forwarded-For или массовом использовании прокси пока не подтверждены; сервер, судя по tcpdump, видит реальные TCP-сессии.
• Игра — это скорее маркетинговый трюк, чем показатель реального контроля над адресами.

Lazy Brush — библиотека для рисования плавных линий мышью, пальцем или любым другим указателем.
GitHub | npm | Reddit

Параметры:

• Lazy radius (60 px) — минимальное расстояние, при котором кисть тянется к курсору.
• Friction (0.10) — инерция: 0 — без задержки, 1 — бесконечная.
• Brush radius (13 px) — толщина кисти, не влияет на логику.

Автор: dulnan

• Библиотека Perfect Freehand и её демо drawmote от автора TLDRaw признаны лучшей альтернативой для плавных подписей и рисования.
• Техника «ленивого» курсора с гистерезисом/стабилизатором уже применялась в Wii-играх, Krita, ZBrush, Black & White и других графических пакетах.
• Пользователи отмечают, что визуальный «поводок» между курсором и пальцем делает рисование интуитивным, особенно на мобильных устройствах и при работе мышью.
• Некоторые считают задержку слишком большой и предлагают использовать фильтр Калмана или DynaDraw для меньшего лага.
• Проект вызвал восторг («лучшее бесплатное», «шокирующе хорошо»), но кто-то жалуется на пропадающие линии и невозможность «естественных» штрихов.

embed-pdf-viewer — легковесный компонент для просмотра PDF, который встраивается в любой JS-проект без зависимостей.

• Установка: npm i embed-pdf-viewer
• Использование:

import { EmbedPDF } from 'embed-pdf-viewer';
new EmbedPDF('#viewer', { url: 'file.pdf' });

• Фичи: масштаб, пагинация, печать, полноэкранный режим, темы.
• Лицензия: MIT.

• Проект использует PDFium (движок Google/Foxit), а не собственный парсер.
• Основная цель — лёгкая интеграция в сайты и более плавный зум/рендеринг, чем у pdf.js.
• В Chrome аннотации работают, в Firefox и Safari частично: ломается выделение текста, закладки, печать.
• Планы монетизации: бесплатный MIT-вьювер + платные enterprise-фичи (хостинг, аналитика, контроль доступа).
• Разработка идёт 7 месяцев; roadmap включает подписание (PKCS#11/12) и, возможно, нативные приложения.

• Zitadel: JS-движок не поддерживает именованные группы в regex.
• Entra: PKCE есть, но не указан в OpenID-доке → клиенты думают, что нет.
• EXIF: размеры в метаданных могут не совпадать с реальными.
• YAML: пробелы ведут себя неочевидно.
• Windows: скрытые файлы нельзя открыть флагом "w"; опция SMB hide dot files усложняет жизнь.
• Git: автопреобразование LF ↔ CRLF ломает bash-скрипты.
• Cloudflare Workers: fetch по умолчанию использует http, даже если указан https.
• Android/iOS: без разрешения на геолокацию GPS-данные могут тихо удаляться из фото.
• PostgreSQL NOTIFY: работает в транзакции → WAL растёт каждые 5 с при использовании socket.io-адаптера.
• npm-скрипты: каждый запрос к реестру → плохой health-check.
• JS-«пакетный» спамер: добавляет 50 лишних зависимостей «для обратной совместимости».
• bcrypt: учитывает только первые 72 байта пароля.
• JS Date: годы и дни считаются с 1, месяцы — с 0.
• ESM ↔ CJS: до Node 20.8 смешанный импорт мог вызвать segfault.
• PostgreSQL: максимум 65 535 параметров — большие bulk-insert ломаются.
• Clipboard API и др. работают только в HTTPS/localhost.
• TypeORM: .remove() удаляет поле id из переданного объекта.

• Пользователи восторженно приняли идею «cursed knowledge» — каталога кошмарных нюансов, сопровождаемого коммитом-фиксом.
• Обсуждали PostgreSQL-лимит в 65 k placeholder’ов, причины появления 50 лишних npm-пакетов, скрытые потоки NTFS/ADS и «призрачные» файлы macOS.
• Упомянули, что bcrypt обрезает пароль до 72 байт, Cloudflare Workers могут игнорировать https, EXIF-даты в Immich — постоянная головная боль.
• Поделились личным опытом: неразрывные пробелы, case-insensitive имена в macOS, Java-классы в Oracle, «магия» YAML-парсеров.
• Кто-то предложил превратить подборку в репозиторий-«Awesome Cursed», другие подчеркнули пользу такого «терапевтического» лога ошибок.

• Установка: npm i -g cursor-cli
• Команды: cursor diff, cursor commit, cursor review, cursor chat
• Где работает: VS Code, JetBrains, Android Studio, Ghostty, Warp, Bash

Функции

• Прямые правки кода в терминале
• Реальное управление агентом
• Правила через .cursorrules, AGENTS.md, MCP

Плюсы

• Последние модели Anthropic, OpenAI, Gemini
• Интеграция в любой IDE
• Скрипты и автоматизация

• Пользователи обсуждают внедрение единого стандарта AGENT.md вместо множества разных файлов.
• CLI-агенты (Claude Code, Cursor CLI и др.) вызывают восторг: удобно держать в фоне, «чувствуешь себя хакером», но UI-IDE теряет значение.
• Критика: непонятно, зачем платить за Cursor, если тот же функционал уже включён в подписку Anthropic/OpenAI; не хватает обратной связи, MCP, hooks и локальных моделей.
• Сторонники Cursor верят в его будущую экосистему (CLI + IDE + GitHub-интеграции) и низкие издержки переключения между моделями.
• Главный вопрос безопасности: доверять ли LLM полный доступ к файловой системе и устанавливать скрипты через curl | bash.