Предисловие от переводчика
Пока вы не добрались до содержимого статьи, советую отложить её, отвести взгляд от монитора, и подумать на тему того, как же это происходит. Как всегда, всё гениальное просто. Ответ на поверхности. Подумали? Тогда читайте дальше.
Ну что же, вот вам корректный ответ. Никак. Это ложь. Точно так же, как ложью является заголовок и содержимое недавно переведённой у нас статьи “Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов”.
Мне казалось очевидным, что это некая небольшая фантазия с лёгким привкусом security awareness, но, кажется, очень многие восприняли её всерьёз, и мне неприятно опять видеть, как из сообщества npm делают груши для битья, не вникая в контекст — так же, как это было, например, после прекрасной статьи “Node.js — раковая опухоль”, или выдранного куска из интервью Райана про то, что ему теперь нравится Go.
Не знаю, намеренно или случайно, но автор написал фантазию по хайповой теме, которую многие приняли за чистую монету. Знаю, что спорить с переводом довольно глупо, но этот перевод стучится ко мне по всем каналам. Так что отвечу ему другим переводом. Поехали.
Пугает безопасность npm? Не поддавайтесь панике!
Так вы тоже в панике по поводу безопасности npm по причине недавних постов? В особенности из-за этого: “Рассказ о том, как я ворую номера кредиток и пароли у посетителей ваших сайтов”. Ну что я хочу вам сказать. В лучшем случае, это троллинговый пост. Давайте расскажу, почему. Почему это глупо, некорректно, выставляет в плохом свете npmjs и поднимает панику на пустом месте.
В начале текста автор описывает свой страшный javascript код, который можно встроить на сайт, чтобы он воровал данные. Автор понимает, что, чтобы получить чужие данные, нужно распространить свой код на другие сайты. Он выбирает для этого npm. Ничего нового и удивительного. Кто угодно может запушить троян куда угодно — в npmjs, python registry и так далее.
Однако, тот факт, что ваш пакет где-то опубликован, ещё не ничего не значит — так же, как, например, если бы вы сделали веб сайт, на который не заходят люди. Так что дальше возникает вопрос — как внедрить троян при помощи самих владельцев сайта? Автор понимает, что это является основной проблемой, и решает её при помощи создания пул реквестов на github, где добавляет свой пакет в зависимости проекта.
Вот и всё.
Вот и весь хак.
Всё содержание текста сводится к этой идее. Никакой магии.
Ни удалённого выполнения кода на серверах npmjs.
Ни удалённых эксплойтов.
Ни meltdown или zero day уязвимостей.
Ни звонка в поддержку npmjs и нашёптывания 2600hz в ушко поддержки.
Давайте-ка я повторю ещё раз
Автор смог распространить свой троян, убедив разработчиков использовать его в качестве зависимости. Офигительно. Дайте-ка я сяду, расслаблюсь и мы рассмотрим этот инновационный вектор атаки.
Без сомнения, для проворачивания такого трюка автор должен быть одарён просто потрясающими умениями социального инжиниринга, так что я могу только отступить и порекомендовать ему пару планов:
- Рассмотреть карьеру в продажах или инвестициях, поскольку автор довёл до совершенства своё умение кратких презентаций.
- Пообщаться с Кевином Митником и совершить ограбление века.
Каким боком здесь npm? Честно говоря, я без понятия. Совершенно не понимаю, зачем кто-то сеет панику в нашем Javascript сообществе. Почему npm явился козлом отпущения? Проблема не в нём. Вернее, там безусловно есть свои проблемы, но с данным рассказом они никак не связаны.
Примечание переводчика: здесь я опустил не совсем удачные аналогии и объяснение на пальцах, почему половина рассказа про воровство паролей это бред сивой кобылы.
Мы вообще понимаем, что работаем в open source?
Сейчас я говорю о всех нас — вы понимаете, что работаете в opensource сообществе? И что это означает? Open source пострен на доверии. На сообществе, на коммуникациях — это основные ценности, которые делают сообщество невероятным, и за которые я его люблю.
Могут ли в open source проекте быть уязвимости? Да.
Могут ли в open source проекте быть проблемы с производительностью, из-за которых кто-то потеряет миллионы на новый год? Да.
Эрик Раймон красиво описал ситуацию, когда обсуждалась уязвимость open source: “чем больше глаз, тем меньше багов" — или, более формально, «при достаточном количестве бета-тестеров и сотрудников почти любая проблема будет быстро обнаружена и окажется для кого-то очевидной».
Когда принимаешь open source, ты принимаешь и риски, который он приносит. Будь это плохой, зловредный или заброшенный код. Так прими же эту ответственность. Ты должен проверять пакеты, которые ты ставишь с npm — npm это всего лишь сервисное звено доставки кода.
Эпилог
Я понимаю, что тот пост был пародийным, но реакция и комментарии показали, что люди восприняли его слишком серьёзно — вплоть до паники. И должен честно сказать, что меня очень сильно огорчило, какое влияние эта статья оказала на имя npm и вопросы безопасности в целом.
Сам я активно занимаюсь компьютерной безопасностью, участвую в Node.JS OWASP проекте, говорю о безопасности в Node.JS на международных конференциях, и так далее. Почему я об этом сейчас говорю? Чтобы показать, что я только за повышение осведомлённости об опасности веб приложений. Но мне грустно смотреть, как из npm и сообщества делают грушу для битья без всякой на то причины.
Не знаю лично Дэвида Гилбертсона, автора оригинальной статьи, но отношусь к нему со всем уважением, и я уверен, что у него не было никаких плохих намерений, и его рассказ это чистый вымысел. Однако я считаю, что мы можем немножко больше верить в интеллект читателей и рассказывать им об опасностях без подобных страшилок. Вместо паники, лучше конструктивно дискутировать по поводу того, как мы можем что-то улучшить.
Послесловие от переводчика
Помимо упомянутых автором аналогов npm в других языках, ещё есть maven, нюгет, composer, есть тысячи фреймворков со своими плагинами и темами, и так далее (если интересно, могу рассказать, как появился вредоносный код в моём wordpress плагине wp-invites, например). В конце концов, есть гитхаб, с которого напрямую можно ставить пакеты в кучу языков — однако никто не не обвиняет гитхаб в том, что там можно опубликовать вредоносный код!
А пинков почему-то достаётся npm. Причём просто тупых и бессмысленных пинков безо всякой морали, выводов и предложений. Ещё и по причине выдуманной истории. Я, как и автор оригинальной статьи, не хочу сказать, что всё прекрасно, и что нет никаких поводов для беспокойства. Всё сломано. Даже наши чёртовы процессоры.
Но не надо устраивать бессмысленную панику. Вы можете починить что-нибудь прямо сейчас. Или написать инструмент для поиска бэкдоров в нпм пакетах (ещё один). Или хотя бы отрепортить баг. Или скинуть пожертвование разработчику. Или внедрить локи и ревью пакетов в своей компании. А можете ныть про ужасный npm. Выбор за вами.
Комментарии (120)
Dargod
12.01.2018 12:37Ждал, что будут описаны механизмы предотвращения попадания вредоносного кода в npm. Но суть тут лишь в том, что админы сами дураки, нужно проверять весь код, и вообще, посмотрите, вон в процессорах нашли уязвимость, типо всё уязвимо.
jehy Автор
12.01.2018 12:43+3будут описаны механизмы предотвращения попадания вредоносного кода в npm
Предотвратить от попадания вредоносного кода в npm на самом деле нельзя. Он может быть в бинарниках С++ расширений, запрятан в исходниках, в подзависимостях, которые тащатся с гитхаба и так далее. Как раз речь о том, что ни один репозиторий пакетов не гарантирует вам безопасности — npm в том числе (хотя они пытаются, за что им плюс). И надо это понимать, а не валить на npm как на единственного козла отпущения. Это всего лишь репозиторий.
Если вас действительно интересует, как предотвратить попадание таких вещей в продакшн, то здесь всё довольно прозрачно, и в комментариях к оригинальной статье на хабре про это уже говорили — только вдумчивый код ревью может помочь (кстати, в самой статье про исправление ситуации тоже ничего не было). И, если вы обнаружили одну такую уязвимость и её отрепортили, то ребята из npm сразу поправят её везде. Помимо этого есть сканеры, например, snyc. Есть различные песочницы, докер и так далее. Всё есть — просто нужно этим пользоваться. И ответственность лежит на вас, и не надо её ни на кого перекладывать.
TimsTims
12.01.2018 12:40+2Без сомнения, для проворачивания такого трюка автор должен быть одарён просто потрясающими умениями социального инжиниринга
Ну да, конечно. Откуда же тогда берутся проекты, в которых +100500 ненужных зависимостей, которые не используются? Это столько много социальных инженеров?jehy Автор
12.01.2018 12:50+2Вы немножко спекулируете на теме.
В статье речь шла про автора, который якобы потратил заметное количество времени на реализацию фич или багфиксов для сотни проектов (прикиньте уже объём работы). А затем он якобы незаметно впихнул туда компонент, который покушается на святое святых, для чего вообще используются только проверенные пакеты — на логи. И якобы 20% радостно влили себе этот апдейт. Вот для этого реально нужны просто фантастические способности социального инжиниринга.
Насчёт лишних зависимостей — проблема есть, но она про другое. Обычно про необходимость совместимости со всеми версиями JS и затаскивание сотен стандартных либ вроде лодаша, бабеля, линтера и так далее. Но из их наличия абсолютно не следует, что авторы радостно добавят себе ноунейм библиотеку от непонятно кого с нулём зависимых в свой проект.
pnovikov
12.01.2018 13:49+1Вот для этого реально нужны просто фантастические способности социального инжиниринга.
Ни разу. Автор так в оригинале и говорит — "it is numbers game". Процент может быть и ниже, однако же динамика положительная. В больше репозиториев PR-нешься — больше заразишь. И если делать это достаточно долго, то в абсолютных числах количество инфицированных репозиториев будет столь же ужасающим. И никаких тебе маркетинговых талантов — просто систематический подход.
jehy Автор
12.01.2018 13:53Да, а "сто старушек — уже рубль". Несопоставимые затраты труда и потенциальный профит.
pnovikov
12.01.2018 13:57Учитывая что куча людей пишут опенсорс запростотак, без профита вообще или ради строчки в резюме, перспектива продажи немаленькой базы данных кредиток вполне себе окупает затею. Ну… мне так кажется с моими представлениями об оплате труда.
jehy Автор
12.01.2018 14:22+11) Вам нужно будет завести кучу аккаунтов на нпм, чтобы вам всё не заблокировали разом.
2) Вам нужно будет прокачать каждый аккаунт, чтобы к нему было доверие
3) Вам нужно прокачать каждый пакет, который вы собираетесь внедрить. При этом зависимость должна быть уникальной и полезной — например, никто не примет ваш клон лодаша просто так.
4) Вам нужно написать разный вредоносный код, чтобы его не выпилили везде разом
5) Вам нужно сделать кучу полезных изменений в популярных пакетах, чтобы ваша зависимость прошла незаметно.
И со всем этим есть ещё риск попасться. Вот правда — слишком сложно. На таком уровне проще сениором работать — скорее всего и денег будет больше, и спать по ночам будете спокойно.
pnovikov
12.01.2018 14:49Эм… а при чем тут прокачка аккаунтов на нпм? Достаточно всего одного аккаунта с одной маленькой либой, которая делает разноцветное логирование. И одного пакета, что в статье и описывается.
Из ваших предположений истинен только п. 5, благо открытых issues в популярных пакетах полно.jehy Автор
12.01.2018 14:55+3Пакетов для разноцветного логирования уже огромное количество, и нет никаких оснований использовать именно этот. Кроме того — вы правда думаете, что ваше разноцветное логирование требуется какому-либо крупному пакету? Так что нужен оригинальный и полезный пакет.
А если делать один пакет и один аккаунт, то вас с большой скоростью отследят и выпилят. Так что истинны все изложенные мной пункты.
Xu4
12.01.2018 18:26Есть такое явление, как «typo-squatting». Можно добавить зависимость на пакет, чьё имя похоже на «оригинальный и полезный пакет». Это вполне может прокатить. Вот реальный пример: habrahabr.ru/company/ruvds/blog/335144
jehy Автор
12.01.2018 18:34Ага, и посылке хорошо показана судьба такого пакета. Не получил и 70 загрузок, был удалён и забанен вместе с остальными пакетами автора, на аналогичный код была осуществлена проверка. А сейчас ещё правила по пунктуации ужесточились и заработал спам фильтр.
justboris
12.01.2018 18:37+1Больше нет. Npm ужесточили правила по этому поводу
Xu4
12.01.2018 18:46Если не ошибаюсь, ситуации с такими названиями это ужесточение не покрывает: react-natiue, react-natiive, react-natjve и т.п.
justboris
12.01.2018 18:54+1Все равно лучше чем ничего. С именами с опечатками они борятся ручной модерацией и автоматической антиспам системой (описано вот здесь, "what we plan to do next").
Кроме того вы всегда можете помочь, есть официальный алгоритм, как добиться удаления спамного пакета.
Судя по тому, что все ваши примеры опечаток как пакеты не зарегистрированы, система работает хорошо.
orange_10
12.01.2018 14:56+1Вы утверждаете, что всегда (100%) внедряются только прокачанные пакеты с прокачанных аккаунтов, исключительно с уникальным и полезным функционалом, и никогда не принимаются мелкие изменения?.. Хм.
Вы наерняка знаете, насколько эффективны фишинговые атаки? Да, 99% людей их смогут избежать, но 1 % который попадается, приносит ощутимый профит, настолько большой, что этим продолжают заниматься.
Иными словами.
Самое слабое звено — люди.
Если вы проведете сто мелких изменений слквых аккаунтов, то есть шанс, что одно примут. Ну а дальше масшатбируйте эти числа))jehy Автор
12.01.2018 14:59Нет, я утверждаю, что большой и востребованный пакет с нормальными разработчиками не примет мелкое изменение, которое включает в себя добавление никому не известного пакета.
Вероятность этого вполне сравнима с вероятностью идти по улице и найти 5000 рублей. Только для хождения по улице ещё и свой код писать не надо. А дальше — масштабируйте сколько угодно...
TimsTims
12.01.2018 15:08Не забывайте, что большой и востребованный пакет зачастую состоит из других мелких и менее востребованных пакетов, которые могут в итоге подцепить к себе эту зависимость, и в итоге такой пакет окажется и в большом… Достаточно внедриться в один из них, и вот — у вас уже многомиллионная аудитория, ничего не подозревающих людей, которые «доверяют большому востребованному пакету».
jehy Автор
12.01.2018 15:18Вам нужно будет
1) Внедриться в маленький пакет. Как вы себе представляете, например, внедрение незаметной зависимости в leftpad?
2) Протолкнуть новый релиз этого пакета
3) Протолкнуть обновление вашего пакета в зависимости верхнего уровня. И так, возможно, несколько раз придётся идти наверх.
4) Чтобы в процессе этого никто вам не заметил.
Ogra
12.01.2018 15:48+1Внедриться в leftpad? Помните ту историю, да? А теперь представьте себе, что обиженный разработчик не удалил свой пакет, а подсунул в него вредоносный код.
Или представьте себе, что кто-то взломал npm аккаунт автора leftpad. Плохие пароли встречаются у всех.jehy Автор
12.01.2018 16:17-3Представил. У всех зафиксированы зависимости и\или используется локи версий. Мало того, что зловред не поставится самопроизвольно на крупных серверах из-за локов, так его ещё и мгновенно отследят.
TimsTims
12.01.2018 15:50+11) Внедриться в маленький пакет. Как вы себе представляете, например, внедрение незаметной зависимости в leftpad?
Во-первых никто не сказал, что зависимость будет невидимой. Она будет видима, но из-за обфускации кода её мало кто прочтёт.
А вариантов подцепиться к такому проекту как leftpad много: приходишь к автору и говоришь: «эй чувак, давай замутим еще rightpad, вдруг кому-то захочется использовать не только лево, но и право?»
Взлом некоей спящей учётки npm тоже отменять не стоит. (upd: упс, меня уже опредили).
4) Чтобы в процессе этого никто вам не заметил
А вы замечаете все изменения во всех 500 зависимостях используемых вами пакетов? Уверены ли вы на 100%, что там нету гадости, или вы, как и другие, полагаетесь, что «ну кто-то то точно это бы заметил»?justboris
12.01.2018 15:55TimsTims
12.01.2018 15:59+1Ну вот, делаем right-pad2, но который «чудесно гибко интегрирован с left-pad». А еще не забывайте, что бывают опечатки (когда пакеты добавляются вручную), и можно сделать «rightpad», «rigthpad» итд итп)
jehy Автор
12.01.2018 16:19Ещё раз — у пакета left-pad есть история и некая авторитетность. У вашего нового — нету. А проблема с опечатками точно так же справедлива для любого репозитория и вообще является частным случаем фишинга.
orange_10
12.01.2018 15:22+2А если (внезапно) проект востребованный, а разрабочики на нем — так себе?..
Однако же вы делаете главную одну ошибку — относитесь к этому вопросу как приличный программист :-)
Поэтому и зациклились на крупных проектах.
Вы мыслите примерно так: «я сделал классный пакет, вложил кучу сил, и теперь хочу, чтобы он 99% попал в этот вот конкретный крупный проект. Это круто, это + в резюме, да и просто приятно.»
Нам всем это понятно, и всем хочется того же…
А нужно мыслить так: «Я сделал вредоносный пакет и мне все равно в какие пакеты он попадет, лишь бы побольше разных — через зависимости рано или поздно подтянется в большое число реальных, боевых проектов»
Это совершенно другая цель. Абсолютно все равно, заразите ли вы 100 сайтов через один большой пакет или через 50 мелких — вы все равно получите то, что хотите.
И, раз уж вы говорите «слишком сложно», то представьте количество даных, которые будет вам сливать ежедневно условный amazon, если вам удастся его заразить… Уверены, что прокачивание аккаунта и написание хорошего фикса того не стоят?)jehy Автор
12.01.2018 15:26И, раз уж вы говорите «слишком сложно», то представьте количество даных, которые будет вам сливать ежедневно условный amazon, если вам удастся его заразить… Уверены, что прокачивание аккаунта и написание хорошего фикса того не стоят?)
Уверен, что есть гораздо более простые способы собирать карточные данные, если вам уж так захотелось to the dark side.
azShoo
12.01.2018 13:02+6Я, конечно, понимаю, что говорю с переводом, но всё же.
Я не увидел в оригинальной статье посыл, что «NPM — зло, давайте забьем разработчиков камнями». Она (на мой скромный взгляд, опять же) про то, что инфраструктура разработки — это тоже вектор атаки на продукт.
И тут хочется отметить несколько моментов:
Первый — автор «ответа» явно передергивает, когда сводит всё к «Автор уговорил разработчиков внедрить свой вредоносный код». Это немного искажает суть: Злоумышленнику достаточно убедить внедрить этот код кому-либо из разработчиков внутри вашего dependency-tree, что бы после обновления зависимостей вы получили у себя в продукте вредоносный код.
Второй — Да, опенсорс строится на доверии. Да, каждый из нас может делать его лучше. Да, подтягивая зависимости мы берем ответственность за последствия.
Это всё очевидно и правильно. Это не отменяет того факта, что в моем домашнем проекте, который я быстро накидал за пару выходных как proof of concept, объем кода в dependency tree в несколько раз больше, чем, собственно, в самом проекте.
Ну, просто потому, что Zen of Python и первая мантра разработчика: не пиши велосипед, используй готовое решение.
И да, я понятия не имею, что происходит под капотом у зависимостей дальше первого уровня дерева (т.е. кроме тех, которые я подтянул сам).
И далеко не у всех команд разработки есть ресурсы (будь-то сила, время или компетенция) изучить полностью древо зависимостей на предмет уязвимостей.
Потому что помимо интерпрайза есть инди-разработчики. Потому что помимо умудренных опытом дримтимов есть ребята, которые делают свой проект на коленке, а потом данные пользователей их мобильного приложения утекают черти куда.
Заслуживают ли такие разработчики пинков коллег, общественного порицания и ночных багфиксов потом? Возможно.
Но их пользователи определенно не заслуживают того, что бы их данные куда-то сливали из-за неосмотрительности разработчика.
Итог:
Сгустил ли автор оригинальной статьи краски про то, как просто всё это осуществить, что бы более драматично обрисовать масштабы уязвимости? Да, определенно.
Действительно ли этой проблеме нужно столько внимания, что бы на её тему поднимать панику и драматизировать? На мой взгляд тоже да.jehy Автор
12.01.2018 13:06Я, конечно, понимаю, что говорю с переводом, но всё же.
Ничего, я тоже эту статью перевёл, отвечая на перевод...
Я не увидел в оригинальной статье посыл, что «NPM — зло, давайте забьем разработчиков камнями».
И я тоже его не увидел. Но многие почему-то увидели. И не увидели, что проблема не только в npm. Ради этих людей автор написал эту статью, а я её перевёл. Рад, что вы к ним не относитесь.
pulsatrix
12.01.2018 16:50Ну, просто потому, что Zen of Python и первая мантра разработчика: не пиши велосипед, используй готовое решение.
Я дико извиняюсь если не правильно понял, но нет в Zen of Python ни слова о велосипедах. Специально перечитал.
Нет языка кроме Питона и Гвидо Ван Россум пророк его.azShoo
12.01.2018 19:20Всё так, всё так. В целом, про велосипеды была отсылка именно к первой мантре разработчика.
Касательно Zen of Python, я бы сказал что в моей голове это тезис хорошо соотносится с Simplicity is better than Complicity, т.к. «не делать лишнюю работу и использовать готовые решения» — тоже часть упрощения твоего кода. Но в целом да, моё высказывание было не до конца корректным.pulsatrix
12.01.2018 23:26«не делать лишнюю работу и использовать готовые решения» — тоже часть упрощения твоего кода.
Упрощение кода — это не всегда верно, кто знает что автор решения нагородил. С другой стороны брать или не брать чужое тоже вопрос. Вопрос в том, что проще — изучить чужое или написать свое. А если не изучать, то встает тот самый вопрос доверия.
SirEdvin
12.01.2018 13:18У npm есть две особенности:
1. Это реально самый большой и быстрорастущий репозиторий.
2. JavaScript в целом использует мантру переиспользования микромодулей, вплоть до упоротого случая с leftpad. На многих других языках разработчики обычно пишут такие функции, поэтому зависимостей получается меньше.
А так да, npm не виноват.jehy Автор
12.01.2018 13:21Это реально самый большой и быстрорастущий репозиторий.
Это вы сейчас минус привели?
JavaScript в целом использует мантру переиспользования микромодулей
Ага. И в микромодуль запихнуть левый код гораздо сложнее, чем в большой.
SirEdvin
12.01.2018 13:23+1Это вы сейчас минус привели?
Это не минус, это особенности. Скажем, вокруг pypi почему-то таких скандалов особо нет. Разве что попытка подмены имен.
Ага. И в микромодуль запихнуть левый код гораздо сложнее, чем в большой.
Как часто вы ревьювите код микромодуля? Вы один раз его глянули и используете. А потом автор туда что-то добавил и код нужно опять ревьюить. Смысл в том, что если вы используете микромодули, то вам нужно ревьюить гораздо больше кода, чем при обычном подходе. Например, в случае проекта на java+spring или проекта python+django у вас обычно ряд классических зависимостей, которые не столь сильно нуждаются в ревью, потому что их разработчикам приходится доверять и 2-3 левых.
В случае javascript пакетов обычно значительно больше.
jehy Автор
12.01.2018 13:29В случае javascript большая часть микромодулей точно так же стандартная. А ещё обновления стабильно работающих модулей обычно лочатся на всю глубину, чтобы на каждый чих не заниматься ревью.
pnovikov
12.01.2018 13:26+1Автор оригинальной статьи, кстати, вполне себе доступен в твиттере для общения.
Критикуется не сам npm. И упор в статье явно сделан не на том, что "ой смотрите, какой плохой npm!". В статье говорится о том, что современный стек JS-технологий таков, что для того, чтобы запустить средней руки приложение вам нужно ну никак не меньше 150 различных пакетов, некоторые из которых вполне себе leftpad-оподобны. И основная печаль в том, что всё JS-сообщество такой подход одобряет и поддерживает. "Да! Даёшь больше как можно мелких пакетов! Ееее, это unix way", говорят они. И вот тут я полностью согласен с автором, что происходящее напоминает какое-то безумие.
Дробление функциональности системы на подсистемы (частным случаем чего является политика распихивания всякого по разным пакетам) — своеобразная дисциплина специальной олимпиады для любого проектировщика. И любой более-менее опытный проектировщик знает как сложно найти баланс между god object (god package в нашем случае) и тысячью маленьких пакетиков, содержащих по одной функции. Так вот. Сообщество JS неосознанно сделало выбор в пользу второго варианта. И это же ужасно. Предыдущие 50 лет человечество старалось минимизировать зависимости при проектировании систем, а тут на тебе — приходит технология, в которой моду диктуют вчерашние бакалавры из около-IT ВУЗов, вдохновившиеся примерами микроядер (иного объяснения такому поведению я не нахожу) и, кладя с прибором на советы более опытных товарищей, начинают громко верещать про то, что маленькие пакеты — это unix way, круто и вообще. А кто так не делает — тот бездарь и вообще пшел вон из профессии.
Фишка в том, что ты можешь проверить все пакеты, от которых зависит твоя система если их, скажем, 10. Или их, скажем, 50. Или — б-г с ним — 100. Но когда их число только начинается от 150 — это решительно не представляется возможным. И это, к слову, только одна из возможных проблем мелкого дробления пакетов. Развивая тему, автор статьи в твиттере давеча написал примерно следующее:
Переведенный твит$ npm install jest > + jest@22.0.6 > added 510 packages in 38.618s
"Эй Jest, хошь прийти ко мне отдохнуть и поглядеть Netflix?"
"Ага, только я возьму с собой 509 друзей. Уверен, никто из них не попытается спереть твой тостер."jehy Автор
12.01.2018 13:37Забавно, что каждый видит в исходной статье нечто своё. Вот вы увидели критику стека JS технологий. Заставляет задуматься о преломлении восприятия даже казалось бы сугубо технических текстов.
Кстати насчёт jest — пользуясь аналогией автора — он-то конечно приводит 509 друзей. Но его самого ко мне приводит фейсбук. И хотя я не жду от фейсбука каких-то абсолютных гарантий, но он является хоть в какой-то мере доверенным поставщиком — точно так же, как любой другой крупный вендор произвольного софта. С такой же вероятностью "спереть мой тостер" может любой разработчик, к примеру, участвующий в проектах google chrome, linux или windows.
pnovikov
12.01.2018 13:43+1Не критику стека, внимание! Критику самого подхода сообщества. Стек-то нормальный но вот политика его развития диктуется, как по мне — так не самыми квалифицированными специалистами, мягко говоря. Но это мое ИМХО.
Фейсбук, если мне память не изменяет, как раз и прокололся на left pad-е. Хоть случай и не совсем релевантный, но он дает четкое понимание что не боги горшки обжигают.
По поводу google chrome и windows — вряд ли найдется инсайдер, который попытается тырить таким образом тостер. В случае google, отлов тостерокрадов — это вопрос доли на рынке, в случае windows — вопрос денег. Насчет linux не уверен.justboris
12.01.2018 15:17Фейсбук, если мне память не изменяет, как раз и прокололся на left pad-е
А можно с этого момента поподробнее? Если вы о Babel, то он разрабатывается сейчас Генри Жу, который в Facebook не работает. Babel — обычный опен-сорс продукт, который используется фейсбуком как и многими другими.
Ogra
12.01.2018 15:50Реакт разрабатываеся Фэйсбуком.
justboris
12.01.2018 15:54Попробовал поставить react в пустую папку, получил такие зависимости:
npm install react L-T react@16.2.0 +-T fbjs@0.8.16 ¦ +-- core-js@1.2.7 ¦ +-T isomorphic-fetch@2.2.1 ¦ ¦ +-T node-fetch@1.7.3 ¦ ¦ ¦ +-T encoding@0.1.12 ¦ ¦ ¦ ¦ L-- iconv-lite@0.4.19 ¦ ¦ ¦ L-- is-stream@1.1.0 ¦ ¦ L-- whatwg-fetch@2.0.3 ¦ +-T promise@7.3.1 ¦ ¦ L-- asap@2.0.6 ¦ +-- setimmediate@1.0.5 ¦ L-- ua-parser-js@0.7.17 +-T loose-envify@1.3.1 ¦ L-- js-tokens@3.0.2 +-- object-assign@4.1.1 L-- prop-types@15.6.0
Лефтпада здесь не вижу
Ogra
12.01.2018 15:59+1История с leftpad была почти два года назад. Судя по этой статье, зависимость была.
justboris
12.01.2018 16:03Зависимость была в Babel, который часто ассоциируют c React, но это не так.
P.S. приводить статью Ализара в качестве пруфлинка — это сильно.
Ogra
12.01.2018 16:08+1Это перевод, и вроде Ализар даже не накосячил (нда, бывает же!) =)
justboris
12.01.2018 16:15Перевод хоть и корректный, но все равно желтый. Ни глубокого анализа, ни проверки фактов там нет.
Но вернемся к исходной теме:
Фейсбук, если мне память не изменяет, как раз и прокололся на left pad-е.
Когда случилась проблема с left-pad, сам сайт facebook.com никуда не упал, работал как надо.
Что прошлая история, что нынешняя, описанная в статье, напоминают об одном: для стабильных и безопасных билдов храним зависимости на своей инфраструктуре, а не тянем с разных чужих доменов. Тогда у вас все будет стабильно, а все эти лефтпады, бабели и другие потенциальные проблемы будут нипочем.
pnovikov
12.01.2018 13:55Ну и в windows как-то… не знаю. В том же C# не принято тащить 150 зависимостей в проект. У нас вот немаленькая система, а nuget-пакетов всего 45, из которых 18 от Microsoft, 3 от Amazon, 5 своих, 1 коммерческий, 7 слишком хорошо известны.
jehy Автор
12.01.2018 14:15Ну так вы же понимаете, что ваши 45 пакетов на самом деле каждый использует ещё кучу своих зависимостей? Просто вы их не видите, поскольку вам уже собранная библиотека приходит. По такой логике, jest это тоже один пакет. Ну и непонятно — если вы верите на слово амазону, коммерческим пакетам и "известным пакетам" — почему вы не доверяете фэйсбуку?
Это я не к тому, что нужно всем доверять, а к тому, что ситуации-то идентичные.
pnovikov
12.01.2018 14:56Ну так вы же понимаете, что ваши 45 пакетов на самом деле каждый использует ещё кучу своих зависимостей?
Нет. 45 пакетов — это уплощенное дерево, вместе с зависимостями (не считая системных dll, которые уже есть в .NET Framework на целевой машине). Так устроен nuget в .NET. Там нет "вложенных подзависимостей" (по крайней мере в той версии, кот. мы используем).
Исходя из сказанного, становится очевидно почему я не верю фейсбуку и его npm-пакетам: в их зависимостях мало ли что скрыто. В nuget и C# зависимые пакеты ставятся явно. А коль пакет тянет с собой 2 dll-ки вместо одной — то я всегда вижу что у меня подключено в References (и там далеко не 150 пунктов).
jehy Автор
12.01.2018 15:01+1Если мне не изменяет память, нюгет в конечном итоге тащит скомпилированные dll. И что в них находится и с чем скомпилировано — одному богу известно.
pnovikov
12.01.2018 15:30Ну видимо я б-г, раз могу разобрать скомпилированную либу рефлектором (JetBrains DotPeek например):)
Если серьезно, то вкомпилить целиком одну dll-ку в другую, конечно, технически можно, но на практике никто из авторов более-менее общеизвестных пакетов этим обычно не занимается. Зависимость поставить и проще и быстрее, и установлена она будет явно. Так же авторы общеизвестных пакетов категорически не приемлют добавление еще одной зависимости в рамках pull request-а. За всех не скажу, но на моей памяти любое добавление зависимости в nuget-пакет сопровождается отчаянной битвой в комментах на гитхабе. Ну потому что когда у твоего пакета ровно 5 зависимостей, каждую из которых ты помнишь и можешь сказать зачем оно надо, то прилетевший пулл-реквест от человека, который ВНЕЗАПНО добавляет ещё одну подвергается тщательнейшему анализу на предмет а зачем оно надо, что оно делает и "может как-то можно без этого?".
Предполагаю, что когда политика всей технологии такова, что 150-200 зависимостей это нормально и плодятся они на каждый чих, то корпеть над каждой автору пакета становится физически трудновато. Ну то есть атака на npm, описанная автором в оригинальной статье — с NuGet-ом не пройдет и будет пресечена чисто на уровне дискуссии в pull request-е.jehy Автор
12.01.2018 15:43Ну видимо я б-г, раз могу разобрать скомпилированную либу рефлектором (JetBrains DotPeek например):)
Это если у вас .NET DLL. Ими мир (и даже нюгет) не ограничивается.
Предполагаю, что когда политика всей технологии такова, что 150-200 зависимостей это нормально и плодятся они на каждый чих, то корпеть над каждой автору пакета становится физически трудновато. Ну то есть атака на npm, описанная автором в оригинальной статье — с NuGet-ом не пройдет и будет пресечена чисто на уровне дискуссии в pull request-е.
Точно так же ведутся дискуссии и в мире npm. Вы почитайте как-нибудь. И поймёте, что всё в точности то же самое. Так что вероятность атаки одинаковая.
pnovikov
12.01.2018 15:49Ими мир (и даже нюгет) не ограничивается.
Само собой. Однако же поверьте, наличие native dll в нюгет-пакете вызывает как минимум оживленный интерес и вопросы "а зачем?", случается крайне редко и соответствующий пакет перед установкой пристально разглядывают. По крайней мере я так делаю.
jehy Автор
12.01.2018 16:21+1Любая криптография, быстрые вычисления, порты нативных библиотек и так далее. Примеры искать лень. И что вы там будете разглядывать, мне интересно.
pnovikov
12.01.2018 16:53-1Любая криптография — это какая? CryptoPro CSP? :)
В остальном, широкий выбор криптографии уже вшит в .NET Framework, сделано MS-ом. Для быстрых вычислений так же есть unsafe mode и уж в чем-в чем, а в медленности вычислений C# замечен не был. Из всего прочего с натягом остаются порты нативных библиотек, но тут смотря что вы имеете в виду. Если, скажем, речь идет о DirectShow, то есть замечательный DirectShowNet — и в нем — сюрприз — нет никаких нативных dll. Остаются только специфические библиотеки для работы с разными устройствами, но их в Nuget обычно не выкладывают.
Словом, если вы пишете среднестатистический веб-сайтик, то вероятность того, что вы столкнетесь с нативными библиотеками стремительным домкратом летит к 0.
staticlab
12.01.2018 15:05+1А сколько же фактически, если не секрет?
К слову, в моём микросервисе на Java сейчас используется 15 maven-зависимостей (включая dev-пакеты), которые фактически притягивают 143 джарника. На прод уходит 128 джарников, включая сам джарник проекта.
pnovikov
12.01.2018 15:1873 .dll-ки наблюдаю в References. Около 20 из них — системные (System.чтото, где я не вижу ни одного незнакомого имени).
staticlab
12.01.2018 16:34Тут у меня ещё есть фронтендный проект, который уже на продакшене. React, redux, router и т.п. Специально подсчитал, сколько же всего пакетов и их зависимостей реально попадает в сборку.
Итого 79. Включая полифиллы.
pnovikov
12.01.2018 16:54С чем я вас и поздравляю, но этсамое… В оригинальной статье речь шла как раз о том, что у вас на этапе разработки 150 зависимостей (часть из этого добра вполне себе может подтягиваться вашими 23мя пакетами неявно) и через них может прокрасться вредоносный код.
staticlab
12.01.2018 14:25А какой подход предложили бы вы?
Возьмём, например, библиотеку lodash. Она не такая уж и маленькая, но и не god object. Вот только она черезчур обобщённая. Поскольку в JS нет перезгрузки функций, то в lodash используются проверки типов параметров в рантайме. Отсюда функции тянут кучу внутренних утилитных функций. Вот, например, sortBy, который может принять на вход и объект, и массив.
В результате, если в проект подключить такую библиотеку, то конечный скрипт для фронтенда может оказаться неоправданно раздутым (недавно я как раз видел, как в относительно небольшую библиотечку впихнули целую Ramda). Тогда разработчик пишет свой sortBy исключительно для массивов, а потом разумно полагает, что было бы неплохо его переиспользовать в другом проекте, да и почему бы не опакетить. Разумеется, в его планы абсолютно не входит писать свою библиотеку разнообразных функций для коллекций, потому он и создаёт какой-нибудь sort-array-by.
Затем другой разработчик, который сталкивается с такой же задачей, но не хочет изобретать велосипед, ищет на NPM подходящий ему модуль. И встаёт перед выбором: тянуть к себе жирный lodash или lodash.sortby, или микромодуль sort-array-by, тем более, что он может быстро просмотреть его код, убедиться, что он делает именно то, что ему нужно, что там нет закладок.
Проблема скорее в том, что при использовании промежуточных библиотек, которые зависят от таких микромодулей, может возникнуть дублирование кода: одна библиотека использует sort-array-by, другая — array-sort-by, третья — lodash.sortby и так далее. В проекте получается несколько реализаций по сути идентичных алгоритмов.
Crandel
12.01.2018 14:31+1Поэтому в нормальных языках все часто используемые функции попадают в стандартную библиотеку и хорошо документируються, чтобы разработчик не лазил по свалкам за небходимым функционалом
jehy Автор
12.01.2018 14:42И какие же это "нормальные языки"?
Может, Java, в которой без сторонних библиотек адекватного HTTP запроса не сделаешь?
Или C#, в котором нет нативной библиотеки для работы с JSON, и все тянут Json.NET?
Или может Go, в котором одной из популярных либ является портированная из PHP библиотека для работы со временем?
Это я уже не говорю о том, что лодаш вообще-то не является прям "часто используемой функцией", и в современном JS не так часто нужен.
Crandel
12.01.2018 14:52+1А с каких это пор HTTP используеться во всех сферах разработки? Или json? Последний кстати из яваскрипта и пришел. До него в мире джавы все xml использовали. У вас кроме веба ничего не существует? Почему в стандартную библиотеку должны попадать функции которые используются только в какой-то одной области? Когда я имел в виду общие функции — то это функции, которые позволяют работать со стандартными типами данных, к примеру сортировка списка. 95% программистов она подходит во всех сферах, а кому надо что-то особенное — ну тогда уже библиотеку можно делать. А не как в лефтпаде
jehy Автор
12.01.2018 15:05+1Да это я просто примеров привёл навскидку. Общие функции вроде сортировки списков в JS есть, если что. У вас откуда-то взялось абсолютно неверное предположение, что в JS нет каких-то базовых вещей.
Crandel
12.01.2018 15:19+1Раз там 150+ зависимостей — тогда там не хватает каких-то базовых функций, потому что ни в питоне, ни в го у меня не было такого количества пакетов в зависимостях, и я имею ввиду все зависимости зависимостей
jehy Автор
12.01.2018 15:24+1А вы сравниваете свой проект с jest — видимо, вы на питоне писали тестовый фреймворк, который должен работать на любой версии языка? Я вот у первого же попавшегося тестового фреймворка на Go вижу два десятка зависимостей с гитхаба (верхнего уровня).
pnovikov
12.01.2018 15:53А вот глядите, тестовый фреймворк на C#. 3 (три!!!) зависимости. Вместе с вложенными — 5 (пять!). Да и эти 5 — чистотехнические декомпозиционные зависимости на другие части этого же пакета от этого же автора.
jehy Автор
12.01.2018 16:28А вы сравните функциональность и того и другого. Ковш для воды и ковш для экскаватора тоже вроде бы оба — ковши. Но есть нюансы.
pnovikov
12.01.2018 15:01-1В C#/.NET есть встроенный функционал для работы с JSON (и с XML тоже кстати), просто Json.NET удобнее и быстрее, к тому же ни от чего не зависит. В остальном на голом C# с 0-dependency уж точно есть всё необходимое — от аналога left-pad (если он вообще кому-то нужен) и нормального API для дат (привет, Java), через встроенного клиента к HTTP/API для сокетов/трединга/асинхронности/web-а/кучи структур данных и примитивов синхронизации до встроенных клиентов к разным базам данных. А если чего-то нет, то легко руками можно выдернуть из windows API.
jehy Автор
12.01.2018 15:07Да это я не в тему того, что шарп или джава чем-то плохи, а просто о том, что ни в одном языке нет полного набора необходимых и удобных конкретному разработчику модулей. Казалось бы очевидным, но видимо нет.
pnovikov
12.01.2018 15:37Само собой нет! Однако и необходимости таскать сторонние библиотеки, на каждый чих, заметьте, не возникает. Сама мысль о появлении, скажем, nuget-пакета, содержащего одну-единственную функцию добавления лидирующих символов к строке… как-то… мнэм… ну как-то так себе. С трудом представляется возможным.
jehy Автор
12.01.2018 15:46Порог вхождения выше, ставить и публиковать на порядок геморройнее. Поэтому и либы сами по себе больше — всё просто. За три года писания на C# я так и не опубликовал ни одного Nuget пакета. Плюс такой довольно сомнительный.
pnovikov
12.01.2018 15:58Порог вхождения выше
Ой-вей, что я слышу! Программирование — оказывается это сложно. Кто бы мог подумать! :)
За три года писания на C# я так и не опубликовал ни одного Nuget пакета.
Ну кто ж вам виноват.
Плюс такой довольно сомнительный.
Очень хороший жирный плюс. Это значит что вы не плодили сущностей сверх необходимости (не изобретали велосипедов), не выкатывая почем зря странный код в паблик и не тратили время сообщества на его обработку, а своё — на его поддержку. При должном уровне скромности это весьма себе неплохой показатель. Или бы вы предпочли сделать что-либо, а вас бы потом тыкнули носом в уже готовые решения внутри самого .NET Framework?
VolCh
12.01.2018 17:47Или наоборот, изобретал велосипеды сотни раз уже написанные другими, но из-за большей сложности публикации в nuget неопубликованные.
staticlab
12.01.2018 14:57Хорошо, а что же делать фронтендерам? Писать на каком-нибудь более высокоуровневом языке с богатой стандартной библиотекой, компилируемом в JS, который сможет тянуть по зависимостям только реально используемые функции? Или писать на языке, компилируемом в wasm, но тогда в бинарник притянется даже реализация массивов и строк?
Crandel
12.01.2018 15:10+1Не знаю, нужно как-то исправлять ситуацию, опыт других языков есть. Просто не надо закрывать глаза на проблему
staticlab
12.01.2018 15:16+1Разве что вносить в TC39 дополнения к стандарту в области расширения стандартной библиотеки.
justboris
12.01.2018 15:22Конкретно left-pad уже встроен в браузеры, проблема решена (вроде бы).
О каком опыте других языков вы говорите?
jehy Автор
12.01.2018 14:36+1Скрипты для фронтенда собирают с использованием инструментов, которые умеют выкидывать неиспользуемые функции. Так что для фронта можно импортировать лодаш и не париться — а то сначала понадобится sortBy, потом ещё что-то… И так и окажется три десятка пакетов вместо одного лодаша.
А для бэка в целом пофигу.
staticlab
12.01.2018 14:44Да, но эти оптимизаторы не смогут понять, какие именно данные придут в тот же sortBy: массив или объект, и потому им придётся тащить всю иерархию зависимостей функции.
jehy Автор
12.01.2018 15:11Тащить придётся всего лишь две реализации для разных видов данных и их зависимости (ну не так их много, правда!). Это ж прям стереотипный случай premature optimization.
pnovikov
12.01.2018 15:15-1А вот решение, друг мой, должно быть чисто в политической плоскости. Иными словами, дизайном standard library должна заниматься одна организация, имеющая для этих целей свой фиксированный штат квалифицированных сотрудников. При том желательно коммерческая и имеющая с качества дизайна standard library свой профит, а не какая-то странная организация-консорциум, в котором непонятно кто заседает и как ведутся дискуссии. В общем я склонен думать, что именно от такой вот "всеобщей демократии" в вопросах дизайна стандартной библиотеки мы и имеем весь действующий трэш, угар и содомию с разными функциями сортировки массивов.
staticlab
12.01.2018 15:18-1Но это произойдёт только если у нас снова будет один абсолютно лидирующий браузер. (И то в своё время Майкрософт не потрудился сделать вменяемую стандартную библиотеку).
pnovikov
12.01.2018 15:42+1Отчего же? Стандарт же есть? Есть. Как-то же договорились о наличии
parseIntво всех браузерах? Ну вот же, вот, "теперь это как-то надо зазернить в катарсисе". Но ECMA тонет в дискуссиях об операторе возведения в степень вместо целенаправленной и квалифицированной проработки стандартной бибилиотеки. Тоскливо это как-то. Обидно.
Лично я это связываю с ущербностью организации самой ECMA (ну так, интуитивно), однако фактическими данными, каюсь, не владею.staticlab
12.01.2018 16:36Если стандарт будет разрабатывать организация, не являющаяся разработчиком браузера (т.е. референсной реализации), то мы рискуем получить EcmaScript 4.
pnovikov
12.01.2018 16:41Короче
если бы я был президентом мира, тоя бы сделал так: аки Steinberg со своим VST сделал бы стандарт для подключения конкретной реализации JavaScript к браузеру, описав бы чисто протокол. А дальше бы в рамках подключаемого модуля — пилил бы референсную реализацию. Но я чувствую, от влажности моих мечт сейчас затопит половину хабра :)
Если мыслить чуть более реалистично, то есть тащемта WebKit, хоть и будучи детищем коллективным, ИМХО в текущих реалиях вполне себе может быть взят гуглом под опеку и принят за стандарт. И типа — хотите нового в JS — идите в гугл. Но черт его знает… не уверен.
VolCh
12.01.2018 13:32Недостаточно знаю как работает npm, чтобы утверждать, что включение в зависимости автоматически приводит к исполнению какого-то кода. В случае composer это точно не так: чтобы запустить код зависимости вам точно нужно что-то написать дополнительно, кроме банального
composer require vendor/package. Если в npm достаточно npm install package и код всех пакетов будет исполняться при первом же require/import, то таки да — это хороший вектор атаки.jehy Автор
12.01.2018 13:42Уже был где-то холивар на эту тему. В npm можно сделать скрипт, который выполнится при установке пакета — так что такой вектор атаки есть. С другой стороны, это мало что значит — в любом софте вы не включаете пакет просто так — значит, вы будете его использовать. Значит, при первом же вызове он сделает своё чёрное дело.
VolCh
12.01.2018 14:09Я именно про сценарий с пропихиванием зависимости в чей-то пакет без её реального использования. Грубо, прислать полезный реальный патч с тремя новыми зависимостями, две из которых реально используются в патче, а третий — нет.
jehy Автор
12.01.2018 14:12+1Скорее всего, неиспользуемую зависимость выкинут из патча. Гораздо проще и логичнее сделать, чтобы она использовалась.
Crandel
12.01.2018 16:55-1А пинков почему-то достаётся npm. Причём просто тупых и бессмысленных пинков безо всякой морали, выводов и предложений.
Действительно, бедный, ни в чем не виноватый npm
justboris
12.01.2018 17:19+1У нормальных разработчиков (если это не стартап 3х человек) поднято свое зеркало пакетов, и от внешних систем не зависит.
Внешние системы, бывает, падают и это нормально, если они бесплатные. Вот и Github
вчера прилег ненадолго, например
JTG
12.01.2018 16:59+5Лично меня та статья напугала (стоит отметить, небезосновательно), а эта не убедила.
yul
12.01.2018 17:52Автор той статьи явно указал на то, что исходники на гитхабе одни, а в npm идет совсем другое, минимизированное до нечитабельности, что, на мой взгляд, вполне может эксплуатироваться, если это так. Не вижу в этой статье опровержения или хотя бы упоминания этого.
artalar
13.01.2018 17:36Я полностью согласен с тем, что система дистрибуции (npm, в данном случае) не может отвечать и, тем более, контролировать распространения каких-либо уязвимостей. Но справедливости ради, оставлю здесь эту ссылку, раз уж речь идет об обвинениях в сторону npm.
На самом деле было бы интересно увидеть какой-то положительный эффект от таких реальных или придуманных историй, в виде формулирования кем-то тезисов, а в дальнейшем, возможно, и стандартов по обеспечению безопасности систем дистрибуции openSource'а и их пользователей.
P.S. продвижки-то естьjehy Автор
13.01.2018 17:56+1Парольная политика это вообще общая боль, как ни странно видеть её в 2017 году в среде разработчиков.
Кстати, не знаю, как она различается в разных репозиториях — возможно npm попал под раздачу опять же из-за хайпа вокруг него.
Подвижки интересные — не знал. Спасибо. Вообще стоит опубликовать ещё и пост по тому, что делать для обеспечения большей безопасности при работе с npm — и какие есть глобальные подвижки.
aamonster
13.01.2018 19:25Жесть какая. Впору переходить на аутентификацию по приватному ключу.
jehy Автор
13.01.2018 19:45Если вы его потом случайно зальёте на гитхаб, то не поможет.
Вообще, уникальных многобайтовых паролей таки хватает. По крайней мере, пока.
aamonster
13.01.2018 20:15Да, действительно. Но сценарий заливки ключа на гитхаб всё же не столь распространён, да и обнаружить его легко.
staticlab
Отчасти как раз такие паникёрские статьи и могут побудить некоторых активных разработчиков к подобным решениям, что уже плюс. Другие же хотя бы задумаются о гигиене зависимостей в своём проекте.
jehy Автор
Если бы в статье был сделан вывод, что нужно проверять любые зависимости в проектах на любом языке — это была бы сразу годная и хорошая статья. Проблема в том, что после её прочтения возникает ощущение, что проблема именно в npm. После прочтения статьи мне люди пишут (дословно): "Жопа с этими нпм пакетами, чел правду говорит же". А те, кто используют другие технологии, считают, что проблема к ним не относится.
staticlab
Да, к сожалению, это так :(
denisemenov
Простите, а вы точно дочитали ту статью?
Как я понял, npm был примером, который люди на эмоциях могли воспринять козлом отпущения. Но у автора была цель не дискредитировать npm, а призвать людей
писать свои велосипедывнимательнее относиться к чужому коду.jehy Автор
А вы точно прочитали моё предисловие и послесловие? Я (и автор переведённой статьи) как раз говорим о том, что, вполне вероятно, что автор ставил себе благую цель, описанную в вашей цитате. Но сообщество восприняло статью (не только на хабре) слишком буквально.
denisemenov
Точно прочитал. А ещё я точно прочитал ваш предыдущий комментарий, в котором вы утверждаете, что никаких выводов автор первой статьи не делал. Как раз в итогах он не указал привязки к конкретному npm, он описал проблему в целом. Участники сообщества и пользователи npm могли воспринять это слишком близко к сердцу и, возможно, просто не смогли отделить одно от другого.
То, что в статье выше написано про аналогии с другими менеджерами пакетов и зависимостей, я с этим полностью согласен, как и автор предыдущей статьи, если судить по его выводам.
Тут косячит сам читатель. ?_(?)_/?
jehy Автор
Пардон, я действительно некорректно сформулировал первый комментарий в этой ветке. Первое предложение оттуда нужно выкинуть.
pnovikov
В конце оригинальной статьи автор недвусмысленно советует критические к безопасности вещи (форма входа, запрос банковских данных) во-первых, детектировать и отдельно прорабатывать (в смысле на уровне подхода серьезнее к ним относиться), во-вторых писать руками и встраивать через
<iframe>(в смысле приводит как один из вариантов практической реализации своего совета).Чем не добротный вывод?
aamonster
Проблема в том, что именно в nodejs-сообществе деревья зависимостей особенно развесистые. Вспомните историю с left-pad.
Т.е. проблема есть у всех, но масштаб разный.
jehy Автор
Чувствую, ещё лет 10 будут этот лефтпад вспоминать.
В шарпе и джаве принято не ставить мелкие пакеты, а не глядя копипастить себе функции и классы с того же SO. Что по сути создаёт неявные зависимости и гораздо более опасно, чем зависимость от микромодулей.
aamonster
Думаю, даже больше :-)
Копипаст функций менее опасен в плане зависимостей: скопированная функция не потянет за собой другую функцию из репы, которая потом обновится. Плюс их всё же читают, тогда как для пакета, вполне вероятно, ограничатся описанием.
Проблема тут другая: в скопированной функции с багом баг не будет исправлен никогда.
А вообще не вижу необходимости вступаться за npm: проблема очевидно не в нём, а в сложившихся практиках. И возможный результат панических статей — не отказ от ноды/нпм, а обострение NIH-синдрома у разработчиков: будут минимизировать зависимости. Ну и жёстко прибивать версии используемых пакетов (проводя перед этим code review всего дерева — что опять же обострит NIH-синдром)