Комментарии 51
Значит я неправильно понял предыдущий коммент. Мне показалось, что там речь о пакетах с npm.
Если это про исходники, то есть вот такое интересное предложение привязать npm-пакеты к их исходникам на Github. То есть сделать ситуацию, когда на гитхабе одно, а в npm другое, было невозможно технически.
Никак. Особо целеустремлённый хакер может сначала долго контрибьютить полезные вещи, завоевывать доверие, а потом тихонько оставить бэкдор.
Поэтому я бы сфокусировался на минимизации поражения, когда хакер уже внутри, то есть грамотное разграничение прав в системе, чтобы ваш линтер не имел доступа к папкам за пределами проекта, тем более — к ключам от кошельков
А где-то есть основания считать, что старый и новый аккаунт использовали два разных человека?
Но адекватного выхода в современных реалиях я не вижу.
Разрабы тащат себе
Вопрос — что делать-то?
Как защититься от «левого» энтузазиста, или прикинувшегося таковым изначального злодея — никто ведь не запрещает влиться в проект и честно его поддерживать, годика эдак два, а потом тихо и мирно вписать в какое-нибудь плохо просматриваемое место «тестовые» данные.
Насколько защищены в этом плане критичные и популярные вещи вроде дистрибов того же Дебиана / Минта / your_fav_ linux'a?
Попросил бы немного развить мысль: в каком production-ready языке эти возможности, на ваш взгляд, хорошо реализованы?
Программы на Haskell быстрее python, php, ruby (и других интерпретируемых языков). Быстрее Erlang/Java (и других vm-based языков). Обычно медленнее Си, хотя я видел несколько случаев, когда компилятор Haskell выдал результат, превосходящий сишный. Для любых практических применений производительности Haskell — за глаза и за уши.
Злоумышленник @right9ctrl не просто добавил бэкдор, но и постарался замести следы. Через три дня он удалил вредоносный код из репозитория flatmap-stream, обновил номер версии
Здесь нужна важная поправка. Злоумышленность пользователя @right9ctrl пока еще не доказана. Да, он добавил новую зависимость вот в этом коммите, но тот модуль опубликован от другого аккаунта: https://github.com/hugeglass/flatmap-stream
Возможно, за аккаунтами стоит один и тот же человек, а может и нет, a @right9ctrl просто добавил новую функциональность, запрошенную пользователями и по неопытности не проверил тот модуль.
На самом деле нет, потому что в данном случае конструкция require('crypto') выглядела как r(e(n[2])). Код был достаточно хорошо спрятан, его, может быть, и не нашли бы, если бы он не вызывал deprecated API, о чем был warning в консоль: https://github.com/remy/nodemon/issues/1442
На самом деле этот сценарий атаки уже был описан примерно год назад: Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов.
Тогда это спровоцировало большое обсуждение и поиск способов защиты. В частности, в npm добавилась команда audit, которая предупреждает о модулях с уязвимостями, двухфакторная авторизация, а в репозитории теперь есть кнопка для репорта об уязвимом модуле, чтобы его оперативно удалили.
Ну и наконец, ждем стабильного релиза deno, принципиальной переделки node, с возможностью запретить делать запросы в сеть любому модулю.
У js есть одна особенность: Вебпак, поэтому вряд ли можно отключить функции запуска процессов, манипуляций правами и всякого такого, нодовские фреймворки стали слишком от этого зависимы (и это кстати тоже проблема). Но разрабы могли бы сделать аналог open_basedir для песочницы, в которой крутятся нодовские процессы. Это сняло бы сразу часть проблем. И в идеале бы, чтобы в этой песочнице запускались и все дочерние процессы. Вряд ли найдётся много кодеров, которые заморачиваются настройкой изолированных сред для запуска самой среды разработки и нодовских процессов, так было бы невозможно работать, нужно решение из коробки как в пхп
github.com/Bo0oM/PHP_imap_open_exploit
Ну, это не первый проблем с npm, вообще то. подробно
Я не JS программист и не понимаю как все это работает, но мне кажется что зависимость от странных незнакомых людей по крайней мере неразумно.
К тому же, если какая нибудь организация (Node.js Foundation) решила делать общественное хранилище библиотек – так контролируйте что в нем находится!
зависимость от странных незнакомых людей по крайней мере неразумно
Ой, ну удалите пжалуйста все ОС со всех устройств — их тоже писали странные незнакомые люди. Пускай каждый пишет себе свою ОС. Вот и наступит рай на земле…
Ну, для начала, это не Node.js foundation, а npm, Inc. Они и следят — как могут. Не будут же они ревьювить каждую строчку кода, которую залил очередной ноунейм.
Ну хоть и гугл. Не можешь, не берись. Те обезьянки, которые берут и пользуются, они думают что все проверено, надежно. Репозиторий официальный, технология самая модная. А в конце получается что я не я и хата не моя. Только, как я уже сказал – в случае с лефт-падом, упала добрая половина веб-а. Теперь бэкдор появился.
Кстати, мне совершенно не интересен npm, node.js и всякие извращенцы. Плохое только то, что некие недоумки криворукие делают глупостей, а ярлык вешают не на npm.inc и не на недоумков, а на все свободное ПО. Вот что бесит больше всего!
"Не согласен — возражай. Возражаешь — предлагай". У Вас есть какие-нибудь более конкретные идеи, что в данном случае мог и должен был сделать npm, чтобы предотвратить проблему? А то, честно говоря, ощущение такое, что мы по большей части застряли на первом этапе: недовольства полно, а реальных альтернатив — не особо.
У меня предложения есть. Ведь, я тоже разработчик свободного ПО. Только карма немного осталась… Но с другой стороной – делай что надо и будь что будет. :D
Вся идея npm очевидно порочная. Автоматическое управление пакетов совершенно не решает ад зависимостей, только усугубляет его, потому что легче становится работать с очень глубокими графами зависимостей.
А надо научится уменьшать эту глубину. И ветки этого графа обязательно надо проходить через библиотеки которые контролируются правильно и большим сообществом. Тогда и риски понижаться значительно.
Вот у меня например зависимостей в текущем проекте от: 1. MUSL; 2. SQLite; 3. И все.
Бэкдор в одной из зависимостей библиотеки EventStream