Разработчики библиотеки event-stream (https://github.com/dominictarr/event-stream/), около 2 миллионов копий которой еженедельно загружается (https://www.npmjs.com/package/event-stream) из репозитория NPM и которая используется во многих крупных проектах, предупредили (https://github.com/dominictarr/event-stream/issues/116) разработчиков о выявлении бэкдора в одной из своих зависимостей. Проблема выявлена в пакете flatmap-stream, в котором под видом тестового набора данных в одной из переменных передавался вредоносный код (https://github.com/dominictarr/event-stream/issues/116#issue...), предназначенный для кражи крипотвалюты и проведения целевой атаки на один из связанных с криптовалютой сервисов.
В частности, вредоносный код мог использоваться (https://github.com/bitpay/copay/issues/9346) для кражи криптовалюты из кошельков на базе платформы Copay (https://github.com/bitpay/copay). Во вредоносном коде также выполнялись манипуляции с файлами, используемыми в библиотеке bitcore-wallet-client (https://github.com/bitpay/bitcore-wallet-client). Не исключено, что атака может охватывать и другие связанные с криптовалютой приложения на Node.js, которые так или иначе связаны зависимостями с event-stream.
URL: https://news.ycombinator.com/item?id=18534392
Новость: https://www.opennet.dev/opennews/art.shtml?num=49665
НИКОГДА такого не было и вот опять
помнити об npm leftad!
А что такого с left-pad?
Samba она такая.
2 миллиона / 7 / N... кхм... девопсиков, безоглядно доверяющих мейнтейнить куски проектов сторонним репам, кхм... снова (что удивительно же!) попали.Внезапно.
два миллиона - это только у тех кто не очень доверяли и зачем-то проверили стотыщную вложенную зависимость своего кода. наверное, тормозил.а сколько лошья еще эту зависимость или зависимость зависимости зависимости понатащило в свои проекты - лет через сто какой-нибудь ИИ сможет посчитать...если этот код его не положит, случайно оказавшись в его внутренностях.
За них композитор эту зависимость проверил. А ревьюить некому, лень, и вообще ненужно.
Я правильно понимаю, что ты вообще никакой сторонний код не используешь и пишешь всё своё? NIH-синдром в терминальной стадии.
Смех смехом, но сильно ли отличаются в этом отношении от ноды другие веб-фреймворки? Куча зависимостей, которая при установке без лишних раздумий тянется из репы или с гитхаба - это намного ли безопаснее?
А дело не в ноде. Ручки-то - вот они, изящно изогнутые. Ревью изменений стороннего кода? Не, не слышали.
каких таких "изменений"? Оно ж с самого начала там лежало.ревью ВСЕГО стороннего кода? Ну тогда какой вам node, вы и на сях-то сами его ни в жизнь ниасилите (хотя там и не доходит до leftpad)
Как минимум - ревью всех изменений стороннего кода от условно-trusted версии вообще обязательно.Или вы предпочитаете вкрячивать не глядя неизвестные изменения, которые сломают неизвестно что в вашем проекте? Если да - примерно об этой категории изящно изогнутых рук я выше и написал.
Для реально серьёзных проектов - да, ревью всего стороннего кода уровня проекта (нет, каждую 100 лет известную библиотеку нижнего уровня ревьюить не надо, это уже за 100 лет сделало коммюнити), затянутого в проект. Причём чем меньше стороннего кода, тем лучше, меньше шансов, что придётся переломать весь проект, когда аффтарам удалённой либы придёт в голову изменить её API до неузнаваемости или просто забить на поддержку.
> Или вы предпочитаете вкрячивать не глядя неизвестные измененияну вы же уже всосали, не глядя, неизвестный код немалого объема - а теперь готовы биться за какие-то там "изменения"?
> которые сломают неизвестно что в вашем проекте
это npm, тут так принято - версия существует самая наираспоследняя, сломалось - срочно переделываем у себя, заодно ломая все что от нас стало зависимым.
иначе бы каждый дурак мог просто зафиксировать версию с устраивающим его функционалом и обойденными найденными граблями - зачем вам новая, если ваш код не собирается использовать ее фич?
> Причём чем меньше стороннего кода, тем лучше
ну см опять leftpad. плата за "простоту" языка - геморрой с элементарнейшими операциями, которые приходится отдельным модулем оформлять.
верно, опять же, и для пихона, и для игого, может в чуть менее идиотической степени.
P.S. и поэтому пихоновский контейнер у меня - с вручную собраными wheels (бо _egg теперь немодно). Поэтому он будет, сцуко, работать, даже через десять лет (и да, локальное зеркало репо с тем самым пихоном тоже есть). Кто знает как повторить этот фокус с composer? С npm не надо, я не настолько долбанутый.
> это npm, тут так принятоДык и я о том )
Ну на самом деле не совсем так, кроме фич бывают ещё багфиксы. Впрочем да, никто не мешает их бэкпортить, это альтернативный вариант селф-сервиса для зафиксированных стабильных веток, но он всё равно ревью подразумевает.
По остальному абсолютно согласен )
>Кто знает как повторить этот фокус с composer?Если я вас правильно понял, то нужно скопировать модуль к себе, жестко заморозить зависимость версии и тянуть возможные изменения этого кода только после обновления модуля у себя в репозитории "руками". Если это так, то нужно поднять свой https://getcomposer.org/doc/articles/handling-private-packag... и указать в composer.json конкретные версии оттуда.
> Если я вас правильно понял, то нужно скопировать модуль к себе, жестко заморозить зависимость
> версиипричем не зная заранее, ни какая версия сегодня модно, ни тем более - что еще он притащит за собой.
(а он притащит, раз использует composer - значит можно быть уверенным, что в зависимостях примерно "весь интернет")satis для этого не предназначен, так можно вручную переварить один-два пакета, а если их десяток, каждый со своими цепочками зависимостей - проще расслабиться и плюнуть.
сломается - ставим задачу разработчикам "срочно почините". Для того и понабрали...
> плата за "простоту" языка - геморрой с элементарнейшими операциями, которые приходится отдельным модулем оформлять.Это вы про C++ boost сейчас?
который из трех...ой, нет, уже четырех установленных?(справедливости ради - boost решает "элементарные" задачи посложнее leftpad. Многим проектам они нафиг не сдались.)
Справедливости ради и leftpad не нужен, т.к. есть нативный метод String.prototype.padStart
> P.S. и поэтому пихоновский контейнер у меня - с вручную собраными wheels
> (бо _egg теперь немодно). Поэтому он будет, сцуко, работать, даже через
> десять лет (и да, локальное зеркало репо с тем самым пихоном
> тоже есть). Кто знает как повторить этот фокус с composer? С
> npm не надо, я не настолько долбанутый.а баги в чужих либах вы как фиксите? или у вас zip.so написан через libgodallknown?
никак, если либа принята в продакшн - она прошла тестирование, в том виде, в котором мы ее используем - значит, скорее всего, если там и есть баги - в сочетании с нашими число их четно, и у нас они не проявляются или костыликом подперты.А когда и если проявятся - значит, переделан прод - значит, смысла в старом контейнере все равно нет, а если при обновлении сломается новая версия - см выше - разработчиков для того и брали, "срочно чините".
И нет - юнит-тестами вы все возможные комбинации звездецов в сторонних либах не покроете. Только комбинация теоретического ревью и актуальных тестов.
конечно нет. И потом - нахрена мне юнит-тесты ЧУЖИХ либ ? Я их не для того подключал, чтоб за авторами горшок выносить. В смысле - ну даже написал, потратив больше времени чем всю либу написать с нуля, ну оно сфейлилось, и что делать будим ? Пойдем чинить апстрим? А нам оно вообще надо? Может мы его в этой позе и использовать-то не собираемся.
Свои, использующие чужое, могут быть юнит-тестами и покрыты - но заведомую диверсию, как тут, они не выявят.
Угу, я именно про юнит-тесты собственных модулей, завязанных на чужие либы.
В либе что-то кромсают, и не факт, что это под тесты влетит.
Да никто не ревьюит второй уровень вложенности. То, что непосредственно проект тянет - да, но то, что ниже - очень вряд ли.Разница в том, что в "больших" языках эти "ниже" обычно и есть "известные библиотеки нижнего уровня", а в джаваскрипте 100500 уровней, и на каждом - не понять что не понять от кого.
Хера себе. То есть можно горе-деплоерам rm -rf / подтянуть в комплекте, и они не заметят? Красиво )
так вот, только ж что и...
(спалили, правда, но это скорее случайность)
Да уж, сколько там ещё такого добра, остаётся только гадать.
>Как минимум - ревью всех изменений стороннего кода от условно-trusted версии вообще обязательно.Но есть ньюанс, хорошее ревью кода обходится дороже написания кода. :)
А поверхностное не заметит, что в зависимости от зависимости в тестовом примере (какой ревьювер за наличие тестов + не поставит? :) ) будет зашит майнер.
И нет, с самого начала оно там не лежало."Why was @right9ctrl given access to this repo? He added flatmap-stream"
Ключевое слово - added.
а что, не нужно было?
я -то имел в виду, что в этом самом flatmap оно лежало.
Ну ревью-то в любом случае выявило бы новую зависимость, к которой нужно отнестись с особым пристрастием )
В ноде дело. В ней невозможно программировать без установки кучи библиотек.
>Ревью изменений стороннего кода? Не, не слышали.Да конечно. Только помрешь раньше чем весь код проверишь.
а причем тут - веп-фреймворки? помимо ноды (которая ни разу не веб и не фреймворк) есть еще прекрасный пихон и еще более прекрасный игого, которые к веппу только тем относятся, что современный разработчик жить не может без http(s) протокола где надо и где не надо.> без лишних раздумий тянется из репы или с гитхаба - это намного ли безопаснее?
это вообще вчерашний день и эпоха довеба. script src=raw.githubusercontent.com/someshit/somemoreshit/shitcode.js - вот как надо!
впрочем, если вы ретро-гад и пишете на пехепе, для вас есть божественный composer, ик...щас он вам накомпозирует!
Да и композерное угрёбище в похе... то есть в пыхе - не отстаёт.
> и еще более прекрасный игогоНа самом деле он реально хорош тем, что стандартного официального набора либ достаточно что бы без особой боли решить практически любую задачу уровня "мне нужен высокопроизводительный (по нынешним мерка) микронекросервис/http-демон" или чего попроще. Ну и понятно - потребление ресурсов хоть по процу хоть по памяти сильно более хорошее чем у какого-нить пыхтона. Если вы готовы в нём писать вычислительные задачи только лишь стандартными операторами (бинарные сдвиги, И/ИЛИ/НЕ и арифметика) работая над байтиками, то производительность его ровно такая же как у С. Хотя памяти безусловно сожрёт побольше, но далеко не как пыхтон. А ещё в нём можно брать и впиливать вставки кода прямо на С, не применяя какие-то особые костыли. На мой взгляд это прекрасная фича которая позволяет решать вопросы работы с ОС если нужных инструментов не нашлось в стандартных либах.
Минус - размер бинаря в который "собрано всё что нужно", это на мой взгляд вообще шаг назад в развитии технологий. И к сожалению выражается он не только в go.
> На самом деле он реально хорош тем, что стандартного официального набора либ достаточновопрос тогда, что считать "стандартным набором" - вот все вот это, что оно понатащило в хомяк, оно ж вполне "официальное", только вот написано хз кем хз как.
> Минус - размер бинаря в который "собрано всё что нужно", это на мой взгляд вообще шаг назад
> в развитии технологий.хм, учитывая "все что нужно" (и то что там по сути go-версии всего содержимого /usr/lib) - размер как раз весьма небольшой.
Но вот про shared libraries да, можно забыть на данном этапе "развития технологий".в принципе, в эпоху горе-контейнеров и недосервисов о них и так уже пора было забыть. Новые модные технологии - mem dedup и прочее, подтянутся.
> вопрос тогда, что считать "стандартным набором" - вот все вот это, что оно понатащило в хомяк, оно ж вполне "официальное", только вот написано хз кем хз как.Не не, я строго про то что идёт в дефолтном архиве с компилером. Т.е. то что было до начала всяких там go get ...
Ибо последнее - это действительно тот же leftpad можно получить.> Но вот про shared libraries да, можно забыть на данном этапе "развития технологий".
И это тоже, хотя они вроде прикрутили что-то уже на эту тему. В общем-то я больше имел ввиду то, что мы теряем общее отображение тех самых либ в память, потому на тыщах контейнеров суммарно мы можем терять уже гигабайты памяти.
> в принципе, в эпоху горе-контейнеров и недосервисов о них и так уже пора было забыть. Новые модные технологии - mem dedup и прочее, подтянутся.
https://lwn.net/Articles/330589/
Не такие уж и новые :) Уж с десяток лет будет. По нынешним меркам - почти динозавр. И оно как-то даже работает, если ручки подкрутить что бы проц не выжирало. Но конечно то ещё костылище.
>script src=raw.githubusercontent.com/someshit/somemoreshit/shitcode.js - вот как надо!если бы ты хоть немного разбирался в теме, то знал бы, что гитхаб такое не позволяет. Советую пойти почитать книжку "http-хедеры для чайников"
>Смех смехом, но сильно ли отличаются в этом отношении от ноды другие веб-фреймворки?Да что там фреймворки - не каждый коммерческий Линукс озаботился доказательной базой, что бинарный пакет собран именно из сырцов, которые выложены на публику. Что требовать от npm?
Пишите про пакеты, где нет бэкдора, если таковые конечно остались...
Мне интересно другое, как отстранившийся от дел автор event-stream так наивно передал проект в руки первого встречного. Чувак с пустым репозиторием и нулевой историей просто на email автору написал, что готов поддерживать разработку, и автор передал ему все права. Один ник right9ctrl уже должен был смутить.
> как отстранившийся от дел автор event-stream так наивно передал проект в руки первого встречногоОн где-то подписывал юридически значимый договор с обязательствами так не делать?
Поэтому мне более интересно как кхм... неназываемо... кхм... решились использовать библиотеку первого встречного неизвестного писателя, даже внутрь не заглядывая.
Потому что они уже использовали сотню таких же на этом проекте и тысячу - на прредыдущих. И сходило, потому что на JS по-другому и не выйдет - на любой чих отдельная либа от кого-то нового и незивестного, все ревьюить - времени свой код писать не будет. Бороться с существующими, а не гипотетическими угрозами - это как бы коммерчески оправданный подход, пусть и далёкий от идеализма.
Ну в общем и получили то, что заслужили. Ничего сверху интересного нет )
Другие пакеты добавили библиотеку event-stream от известного автора 100 лет в обед.
Недавно автор библиотеки передал её на поддержание первому встречному, а тот добавил вредоносный код в качестве новой зависимости. Но в репозитории на github этого нельзя заметить, плохой код находится только в минифицированной версии устанавливаемой из npm.
Есть простое правило: любой апдейт сорцов сторонней либы, прибитых к собственному проекту, должен ревьюится. Если это правило не соблюдать - в следующий раз например все номера кредитных карт ваших клиентов будут у разных людей.
Попробуй в одиночку всё отревьювить. Мне например вообще проще микро зависимости вроде всяких лефтпадов не подключать, а добавить пару лишних строк код. Из моих зависимостей оказался только nodemon инфицирован. Но всё проверить не реально.
> Попробуй в одиночку всё отревьювить
> Из моих зависимостей оказался только nodemon инфицирован:) Ну о чём и речь, если не ревьюить - будет засада.
Иногда лучше вообще никак, чем так.
лучше не программировать вы хотели сказать?
Ну в общем да. "Не умеешь - не берись", есть такая фраза из старины.
В старине ещё ездили на телегах, спали на лавках, избы по чёрному топили, а питались тем что сами вырастили и тем, что боженька подаст. Сказать-то ты что хотел?
>любой апдейт сорцов сторонней либыВы в пролете с таким правилом - сорцы были в порядке. Минифицированная версия нет. :)
>>любой апдейт сорцов сторонней либы
> Вы в пролете с таким правилом - сорцы были в порядке. Минифицированная версия нет. :)вообще это важное замечание
всё ещё хуже для мантейнеров...
вот вроде бы ответ из первых уст: https://pbs.twimg.com/media/Ds8nulwXgAAd4bv.jpg
типа чел попросил, мейнтейнеру не жалко было
> Мне интересно другое, как отстранившийся от дел автор event-stream так наивно передал
> проект в руки первого встречного. Чувак с пустым репозиторием и нулевой
> историей просто на email автору написал, что готов поддерживать разработку, и
> автор передал ему все права. Один ник right9ctrl уже должен был
> смутить.а что он должен был сделать? какой тест профпригодности есть для передачи или добавления мантейнерства?
Неплохо. Новый вызов опенсурцу: как поддерживать базу кода невероятного объёма, пресекая активность злодеев? Простор для генерации идей, между прочим, а возможно даже для успешных стартапов.
У нормальных проектов, разрабатываемых по нормальным методикам, а не в виде краудсорсинга кода неизвестного происхождения, этого вызова нет. Всякие хипстерские поделки - страдают и будут страдать.
Если проект разработан нормально он не может тянуть 10 000 зависимостей каждая из которых тянет еще 10-100 зависимостей? Авторы типа сами все либы перепишут? Или заморозят их и никогда не будут обновлять даже, если найдут там ошибку? Или перепроверят все 10 000 перед тем как будут писать код? А если хотя бы 1/100 из этих либ обновляется раз в 5-7 дней они будут проверять не исправили ли там что-то критичное? Может тогда и ядро linux эти мифические разработчики тоже сами переписывают, а то вдруг там баг или эксплоит? Или замораживают его и не обращают внимание яна всякие Specter и Meltdown?
> У нормальных проектов, разрабатываемых по нормальным методикам"Нормальные" методики в твоём понимании -- это разработанные дедами? Откуда такое неверие в будущее и преклонение перед прошлым? Ты не христианин случаем? У этих всё мировоззрение основано на грехопадении и постепенном загнивании человечества, типа вчера всегда лучше чем завтра.
> Всякие хипстерские поделки - страдают и будут страдать.
Это слишком сильное утверждение. Страдают, это да. Но так или иначе они будут вынуждены найти способ не страдать.
> Но так или иначе они будут вынуждены найти способ не страдать.переложить ответственность на никого, отличный способ не страдать.
>> Но так или иначе они будут вынуждены найти способ не страдать.
> переложить ответственность на никого, отличный способ не страдать.Для некоторых -- да.
Нет, я технократ. За такие поделки надо редактор от сети отключать и аффтару, и всем "писателям", использовавшим это без ревью - пусть в стол пишут сначала, потом в паблик.
>> У нормальных проектов, разрабатываемых по нормальным методикам
> "Нормальные" методики в твоём понимании -- это разработанные дедами?Ну не малолетками же, которые и впрямь ложку в ухо упорно несут.
> Откуда такое неверие в будущее и преклонение перед прошлым?
> Ты не христианин случаем? У этих всё мировоззрение основано
> на грехопадении и постепенном загнивании человечества,
> типа вчера всегда лучше чем завтра.Вы и в этом некомпетентны. Озадачились бы уже, что ли, изучением матчасти -- можно и матметодами, между прочим, некоторые метрики вполне исчислимы и сравнимы.
> Вы и в этом некомпетентны.Сказаал модератор форума школоло-эникеев. Очень убедительно вышло.
> Откуда такое неверие в будущее и преклонение перед прошлым?Любой действительно мыслящий человек понимает, что «новое» и «лучшее» — не синонимы.
Всякое «новое» обязано доказать своё преимущество над уже существующими вещами.
>> Откуда такое неверие в будущее и преклонение перед прошлым?
> Любой действительно мыслящий человек понимает, что «новое» и «лучшее» —
> не синонимы.Чёт тебя понесло в тривиальщину. Умные мысли кончились?
> Всякое «новое» обязано доказать своё преимущество над уже существующими вещами.
Да-да. Тут целый форум дeбилoв, которые сидят и ждут, когда им что-то там докажут. Они искренне уверены, что кто-то обязан им что-то доказать. Я несколько лет наблюдал, думал, может они не столь тупы как кажутся, может дождутся когда-нибудь. Но не, априорные оценки оказались верны, шансов у них ноль.
> Чёт тебя понесло в тривиальщину. Умные мысли кончились?Я ещё не отсмеялся, прочитав пафосные рассусоливания миллениала про индивидуальную мораль и остальную хипсторскую чушь. Ты слишком необразован, дружок, чтобы осознавать свою глупость. Эффект Даннинга—Крюгера во всей красе. :)
>> Чёт тебя понесло в тривиальщину. Умные мысли кончились?
> Я ещё не отсмеялся, прочитав пафосные рассусоливания миллениала про индивидуальную мораль
> и остальную хипсторскую чушь.Слишком сложно? Книжки надо читать чаще, тогда проблем с пониманием текстов длинее 1kB не будет.
> Ты слишком необразован, дружок, чтобы осознавать свою
> глупость. Эффект Даннинга—Крюгера во всей красе. :)Старпёр, хвастающийся знаниями мемов. Выглядит забавно.
Хочешь я расскажу тебе как ты можешь оценить свою подверженность эффекту Даннинга-Крюгера? Вот смотри, эффект Даннинга-Крюгера родом то ли из общей, то ли из социальной психологии. Какие ещё эффекты из общей или специальной психологии ты можешь вспомнить навскидку? Составь список.
Составил? А теперь пройдись по этому списку и вычеркни оттуда то, что знает 95% интернета. Остался хоть один пункт? Количество пунктов, оставшихся не вычеркнутыми, говоряще. Другое дело, что я вот только что придумал этот метод, и я не пытался хотя бы прикинуть, как бы так из этого числа пунктов сделать осмысленный и определённый вывод. Типа если один пункт -- то человек попадает в 10-й процентиль, если 3, то в 50-й, если 10, то в 95. Точные значения нам неизвестны, но если тебе хочется объективности, ты можешь их измерить, сегодня набрать выборку в онлайне в полтысячи человек, которые заполнят опросник -- это дело получаса создания опросника в гуглоформах, две недели на CEO этого опросника, и потом два дня на обработку результатов. Учебник матстатистики, если надо, я могу порекомендовать.
Ну так вот, возвращаясь к Даннингу-Крюгеру: чья бы корова мычала, а уж твоей бы точно помолчать не грех.
Феерический невежда. Ещё и хам и графоман. :-)
> Феерический невежда. Ещё и хам и графоман. :-)Ты так говоришь, будто только сейчас это понял. Тупой что ли?
> Феерический невежда. Ещё и хам и графоман. :-)Кстати обо всех этих эвристиках и байесах, как всегда как на заказ напоролся тут на ссылку: https://www.visualcapitalist.com/24-cognitive-biases-warping.../
Первая половина из этих 24 байесов -- это сплошные мемы, которые известны любому, кто хоть раз задумался о том, что такое когнитивное искажение и спросил у гугла. Я полагаю, что любой человек, кто провёл в интернете 5+ лет слышал про каждый из них хотя бы раз. Хотя, это моё суждение основано на aviability heuristic, то есть просто я на них натыкаюсь регулярно. Вторая половина, на мой взгляд, менее меметична, но если тебе приходилось читать Thinking, Fast and Slow, то часть из них ты признаешь обязательно, ту же aviability heuristic, например.
То есть, если ты не хочешь выглядеть дилетантом, переоценивающим свои познания, то лучше не ссылаться на мемы из первой половины вообще. А в свете того, что тот же Канеман открыто признал, что порол чушь, поскольку сам оказался жертвой тех эффектов, которые описывал, и половина его эффектов не воспроизводится в экспериментах других людей, то лучше вообще не ссылаться на эти эффекты, если ты не можешь вспомнить, какого размера была выборка у исследователя, зарегистрировавшего данный эффект. Но если тебе плевать, и ты как всегда просто лепишь в кучу все слова, которые можешь вспомнить, лишь бы они при этом увязывались между собой без грубых нарушений правил грамматики и стиля, то конечно можно не париться на этот счёт.
Как обычно - ревьювить все пул-реквесты, не мержить что попало. А комитить в мастер-ветку разрешить только хозяевам репозитория.
> Как обычно - ревьювить все пул-реквесты, не мержить что попало. А комитить
> в мастер-ветку разрешить только хозяевам репозитория.и что вы сделаете с пулреквестом добавляющим зависимость от либы делающей "нужно" для использования вашего самописного костыля делающего "нужно"?
вы проревьювите весь код той либы которая на первый взгляд действительно нужно делает "нужно" и во многих вариантах умеет делать "нужно" разными методами по разным входным данным
а ещё она использует небольшую либку для красивого вывода "нужно" в лог, а в ней есть тестываше решение, мастер?
Да каждый ответить, что либа которая делает "непонятно-что", но у которой есть тесты, в разы лучше той, у которой их нет, что уж говорить про велосипед...
> для успешных стартапов.пилите антивирус для сабжа ;)
"успешный стартап" только что намайнил/свистнул чужие пару десятков btc, и еще сопрет. Нафига тут что-то строить, когда гораздо проще и интереснее ломать, а прибыль выше?
https://ru.wikipedia.org/wiki/Предотвращение_утечек_информации
> https://ru.wikipedia.org/wiki/Предотвращение_утечек_информацииа в реальности оно работает никак
или вы сидите в закрытом ящике и пишете целиком свою Ось, и это должна быть явно не ОС МСВС
Это мне напомнило старую статейку на хабре:
https://habr.com/company/ruvds/blog/346442/
веб уже ничто не спасет
как же так? видь это же репозиторий у которого есть мантейнеры!!! как же такое могло произойти???хотя ладно, тут либа ломает приложение которое зависит от этой самой либы, я вот не знаю как в лине от такого защищаться и можно ли вообще?
> около 2 миллионов копий которой еженедельно загружается из репозитория NPMКто все эти люди?
Так это не люди. Там зависимость на зависимости с зависимостью. Ты мог сделать npm install webfignya, а у тебя один пакет скачался 20 раз, потому что он в зависимостях у 30 пакетов.
На зависимостях из NPM можно классный ботнет соорудить.
а есть там пакет у которого в зависимостях "все" ?
его еще не плохо было бы впропихнуть в зависимость ко всему. :)
VSCode зависит от event-stream. Если ваш мейнтенер (или вы) собрал его с зараженной версией либы, то пропали ваши коины. Нормальненько так.
> VSCode зависит от event-streamбггг.
с другой стороны - ну крановщик же не хранит свою заначку от жены в кабине крана на стройке где работает? Вот и вы ховайте под рельсой, там не найдут.
> крановщик же не хранит свою заначку от жены в кабине крана на стройке где работаетА вот тут дедка надвое сказала. Которая была бы бабкой при определённых условиях, конечно, но не сложилось.
DLL hell, version 2.0"Умные учатся на чужих ошибках, простые люди на своих и только дураки никогда ничему не учаться..." (c) 0001 Народная мудрость.
Тебе бы не мешало поучиться русскому языку.
Так я с ним родился, с русским, куда еще больше учить... ну а на счет typos, sorry...
DLL hell
это вообще про конфликт зависимостей, ник не оправдали если даже такое не знаете
Название темы: "Бэкдор в зависимости", отсюда версия 2 :) раньше конфликт, теперь backdoors. А сарказм от того, что терпеть не могу зависимостей, что в жизни , что в soft-e ...
Интересный тут ср@ч развели, конечно. Но речь вот о чем. Веб-приложения на Node, либо на браузере обычно тянут сотни зависимостей.Если условно выбрать какую-то версию и зафризиться на ней (но все сторонние компоненты проверить), то есть шанс потом вообще никуда не обновиться. Другой вопрос - а надо ли? Иногда проще с нуля все переписать.
Вообще в университете физик говорил: "Парни, запомните! Чем больше зависимостей - тем меньше степеней свободы )".
Вот и получается, что по-хорошему надо этих самых зависимостей делать меньше. Потому что их надо: a) проверять, б) апдейтить, в) следить, чтобы ничего не сломалось. А на поддержку всего этого тратится уйма времени.
Если рассуждать логически, то основная проблема в том, что NPM не следит за тем, что добавляют в их репозиторий и не проверяет на достаточном уровне.
Это как с AppStore от Apple и их системой модерации, или PlayMarket от Google. Где меньше порядка и слабее модерация - больше вирусни.
В общем и целом, да, надо следить за сторонними изменениями, либо же делать свой NPM c блекджеком и репозиториями
Корень еще в том, что вендоры библиотек не заботятся о выпуске стабильных релизов, а считают, что все можно поправить, закоммитив в мастер на следующий день быстрофикс.Просто надо настроить себя не рваться за большим колисчеством и свежестью 3rd-party либ для своего проекта. Взял либу - так и сиди на ней. Что касается безопасности, то дыр в ней, как мы видим наглядно, меньше, если её не обновлять.
> Корень еще в том, что вендоры библиотек не заботятся о выпуске стабильных
> релизов, а считают, что все можно поправить, закоммитив в мастер на
> следующий день быстрофикс.
> Просто надо настроить себя не рваться за большим колисчеством и свежестью 3rd-party
> либ для своего проекта. Взял либу - так и сиди на
> ней. Что касается безопасности, то дыр в ней, как мы видим
> наглядно, меньше, если её не обновлять.Да, тоже дельный совет. Можно лочить версию пакета, чтобы случайно так не обновиться.
Другой момент - юнит тесты же не просто так пишут. Да и вообще тестирование не просто так существует.
NPM? ...да здравствует YARN... (https://yarnpkg.com/lang/en/)