htmx 4.0.0 вышел после восьми месяцев разработки, сосредоточившись на стабильности и будущей долговечности — с целью создания веб-сервисов, работающих 100 лет. Главное изменение: атрибуты больше не наследуются автоматически, а требуют явного указания через :inherited (например, hx-confirm:inherited), что устраняет неочевидное поведение из прошлых версий. Для миграции доступен инструмент командной строки, автоматически находящий места, где нужно добавить :inherited.

Внутренне библиотека перешла с XMLHttpRequest на современный fetch(), что упростило код и позволило реализовать стриминг HTML. Имена событий стандартизированы, а поддержка истории больше не использует localStorage, убрав частые проблемы с отладкой. Несмотря на изменения, поведение 4.0 почти идентично 2.x — обновление необязательно: NPM оставит 2.x как latest, пока 2027 год. Для разработчиков, использующих LLM, выпущены специальные файлы с руководствами по миграции, отладке и написанию расширений.

Тред в основном поддерживает релиз, но добавляет несколько практических наблюдений: реальный опыт миграции с Turbo/Hotwire на htmx 4 в Rails-приложении (@dajonker), сочетание с agent-driven разработкой благодаря простой HTML-разметке (@bluesnowmonkey, @arjie), подтверждение востребованности обновлённой совместимости с Alpine через alpine-ajax (@james2doyle), а также контраргумент из .NET/Angular-стека о возврате к смешению UI и бизнес-логики (@rednb). Шутка про «CEO of HTMX» стала мемом треда.

• htmx ценят за простоту, низкий порог входа и органичный рост без корпоративных амбиций; многие отмечают, что агенты и vibe-coding отлично работают с гипермедийным HTML, потому что UI можно тестировать без headless-браузера (@bluesnowmonkey, @arjie, @havaloc, @nzoschke).

• Наследование атрибутов через явный `:inherited` воспринимается как спорное, но потенциально полезное для читаемости (@jamesforestwest, @ryanisnan отмечает, что кроме статического HTML лучшей альтернативы для «100-летнего веба» он не видит).

• Совет: @james2doyle на практике заменил htmx связкой Alpine.js + alpine-ajax (~10 КБ), получив все нужные фичи и обойдя проблемы совместимости hx-alpine-compat.

• Совет: @dajonker в проде на Rails заменил большую часть Hotwired/Turbo на htmx 4, используя ActionCable для пушей вместо Turbo Streams, и отмечает, что с htmx поток контента управляется с клиента, а не с сервера.

• Спор: @rednb, опытный .NET+Angular разработчик, считает htmx шагом назад: возврат к генерации UI на бэкенде смешивает presentation с бизнес-логикой, а серверное управление состоянием в нетривиальных SPA сложнее TypeScript. Ему возражают сторонники SSR-подхода (@nzoschke: Go+htmx+SQLite как простой и быстрый стек), показывая, что «шаг назад» зависит от класса задач.

• alpine-ajax и Datastar упоминаются как реальные альтернативы/дополнения к htmx (@james2doyle, @threesmegiste: Datastar вырос из идей htmx, @teknico).

• Спор: @replwoacause сомневается в долгосрочной ценности htmx в эпоху LLM, которые могут генерировать JS напрямую; @threesmegiste и @ryanisnan контраргументируют, что простота и независимость от JS-цепочек инструментов остаются преимуществами, особенно для долгоживущих сервисов.

• Совет: Несколько пользователей (@cubefox, @hollowturtle) сообщают о практическом баге: якорные ссылки в секции «On this page» ломаются на Mobile Safari и Android Firefox/Chrome — регрессия 4.0.0, не упомянутая в статье.

• Мем треда — самопровозглашённые «CEO of HTMX» (@Baguette5242, @dec0dedab0de, @hmokiguess, @miguel-muniz, @alkonaut), породивший шутку про домен htmx.ceo и реплику «у нас больше CEO, чем пользователей» (@alkonaut).

• Совет: @praseodym и @orsenthil независимо заметили, что обложка релиза (джип) совпадает с обоями Omarchy Quattro/DHH; @alsanan напоминает, что истинный драйвер 4.0 — проект fixi того же автора, более минималистичный преемник.

Инструмент @openai/codex-security — это CLI и TypeScript‑SDK, позволяющие обнаруживать, проверять и исправлять уязвимости в коде. Требуется Node 22 или новее и Python 3.10 +, а также доступ к Codex Security. Установка через npm i @openai/codex-security, вход командой npx codex-security login и сканирование репозитория npx codex-security scan .. Для CI можно использовать переменную OPENAI_API_KEY вместо входа, а при наличии обоих учетных записей интерактивный скан запрашивает выбранный метод; в неинтерактивных режимах приоритет остаётся у API‑ключа. Параметр --auth chatgpt или --auth api-key позволяет явно указать источник.

Результаты сканирования сохраняются в рабочем каталоге Codex Security; если запись недоступна, задайте CODEX_SECURITY_STATE_DIR на записываемую директорию. Для работы с TypeScript‑SDK импортируют CodexSecurity из пакета, создают экземпляр, вызывают run('.'), выводят reportPath и закрывают соединение close(). Всё необходимое о параметрах сканирования, настройке CI и дополнительных опциях описано в официальной документации. Интересный факт: при конфликте учётных данных интерактивный режим предлагает выбрать источник, а в автоматизированных пайплайнах предпочтение отдаётся API‑ключу, что упрощает интеграцию в существующие workflow. Кроме того, можно фильтровать результаты по уровню угрозы через --severity и экспортировать отчёт в JSON для дальнейшего анализа.

Тред обсуждает практический опыт использования Codex Security: пользователи отмечают высокие затраты и ограничения по скорости запросов, что может быть проблемой для крупных проектов. Есть споры о его эффективности — одни считают инструмент полезным для обнаружения уязвимостей, другие сомневаются в его способностях. Рекомендуется использовать опцию --max-cost для контроля расходов. Codex Security сравнивают с Snyk и Strix, обсуждая его потенциальное влияние на рынок безопасности.

Perl не мёртв, его популярность находится на уровне периода dotcom пузыря, согласно отчёту CPAN 2023. Новичков среди пользователей Perl становится всё меньше с 2011 года, хотя общее использование языка остаётся стабильным. Raku (бывший Perl 6) не стал причиной упадка, так как Perl продолжал расти даже во время разработки Raku.

Основные гипотезы упадка Perl связаны с изменением поколений программистов и развитием инструментов разработки. Программисты, выросшие на Unix-системах, естественно воспринимали Perl как продолжение shell, C, awk и sed. Новое поколение, воспитанное на Microsoft, Visual Basic и Java, предпочло Python. Кроме того, появление мощных менеджеров пакетов сделало доступными множество альтернатив, в то время как раньше Perl был одним из немногих доступных инструментов.

• Perl умер не из-за Raku, а из-за отсутствия единого пути развития, отсутствия стандарта кодстайла и культуры «один-разовых» скриптов.
• Python и PHP выиграли, потому что они были «дружелюбнее» для новичков и имели лучшую документацию.
• CPAN стал менее удобным, чем PyPI и npm, что сделало Perl менее привлекательным.
• Отсутствие единого фреймворка для веб-разработки и отсутствие стандарта ООП в Perl 5.
• Не было единого сообщества, которое могло бы продвигать Perl, в то время как Python и JavaScript имели Google и Facebook.

Инструмент 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) и необходимость улучшения документации, особенно для новичков.

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

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

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

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

Как устроен 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.

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

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

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 для меньшего лага.
• Проект вызвал восторг («лучшее бесплатное», «шокирующе хорошо»), но кто-то жалуется на пропадающие линии и невозможность «естественных» штрихов.

• Установка: 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.