Comments 33
Думаю, дьявол ещё не заходил так далеко
Великолепно. Я тут недавно налетал на установку 8 тыс пакетов при желании получить один, но там бага оказалась https://github.com/stdlib-js/stdlib/issues/1199
(вспоминает какие еще штуки в инете имеют аналогичные свойства с зависимостями)
кто знает - а для докера, мавена и апт пакетов такое же есть?
Реквестирую неделю everything для everything.
А что вам может помешать такое сделать, ну разве что кроме размеров файла pom.xml (учитывая, что число артефактов в централе кажется уже давно перевалило за 10 миллионов, не считая разных версий). Другой вопрос - как это может сломать тот же централ? Для него это просто огромный артефакт, на зависимости репозиторию наплевать по большому счету. Хотя нет, UI централа нынче показывает зависимости (и даже уязвимости в них), вот его запросто сможет сломать.
ну делаем как для нпм сделали - промежуточные пакеты (по пять тыщь зависимостей в каждом, которые потом используем в нашем: 5000х5000 = 25 млн)
просто я к тому что "выставленное в интернете" - это же готовые цели для ДДОС и "атак сибиллы" %)
Атака-то на кого? Этож надо чтобы кто-то это хотя бы скачать попробовал. Не могу сходу себе представить, чтобы кто-то с какой-то целью пытался скачать такую зависимость.
Смотрим описание из текущей статьи:
По статистике NPM пакет был загружен около 250 раз, но никто не мешает добавить его в зависимости к другому пакету после взлома учётной записи разработчика для совершения диверсии.
Ну как бы, это совсем несерьезно. 250 каких-то странных людей загрузили, и чо? Вот меня-то как разработчика что может заставить включить в список своих зависимостей некую непонятную хрень под названием everything? Причем заметьте - в случае мавен централа у вас не выйдет опубликовать зависимость от имени условной Apache Groop, только под своей учеткой (вопросы взлома - опять же за рамками эксплуатации именно этой уязвимости). Так вот если непонятная хрень еще и опубликована непонятно кем - шансы что я ее подключу к проекту реально нулевые (еще на минутку, мне для начала нужно узнать о ее существовании).
Не говоря уже о том, что после "взлома учетной записи" можно сделать любые другие гадости на выбор.
Взломают не вас, а зависимость, которую вы ставите себе в проект.
Это немного не так работает. В JS куда больше мелких библиотек, чем в Java. Например, если тебе нужен какой-то продвинутый trim строки, ты не пишешь его сам, а идешь искать в NPM. Таких пакетов через некоторое время только у твоего проекта обнаруживаются десятки и сотни. А у твоих мелкобиблиотек есть свои зависимости, потому что условный trim может звать какой-нибудь продвинутый substring или regex, который тоже лежит в отдельном пакете. А уж сколько всего интересного может быть в зависимостях у regex...
В Java обычно куча мамонтов, которые ставят какой-нибудь Spring, Apache Commons и на этом ограничиваются, для них добавить либу для trim будет немыслимым вложением усилий, они лучше на коленке сами наговнякают плохо работающую херню, или со StackOverflow скопируют. Кажется, единственный плюс такого криокамерного подхода вот этот - меньше вероятность, что у тебя что-то там взломают.
Ну то есть, я не хочу сказать что атаки на механизм поставки зависимостей глупость или ерунда, я хочу сказать что в таком виде это не более чем забавно.
Для AUR давным-давно есть ffmpeg-full-lib32 с похожим эффектом.
Для докера это будут радужные таблицы хэшей слоёв/манифестов, только придётся некоторое кол-во галактик переформатировать под хранение.
А на какие затраты можно высадить всех кто собирается в облаках, если на какой-нибудь пакет, от которого дофига всего зависит влепить это в зависимости. Билды будут падать, и если настроено рестартиться до победного будут жрать сеть, диск, время.
Вообще это феерично: вместо исправления уязвимости «отработало с администрацией GitHub возможность скрытия этого проекта на ресурсе»...
Кроме того, что сам подход к проблеме феерический, очевидно, что теперь будет много желающих сделать что-то подобное.
Вообще это феерично: вместо исправления уязвимости «отработало с администрацией GitHub возможность скрытия этого проекта на ресурсе»...
Видимо, попытка исправления привела бы к ситуации "хакер и солонки".
К тому же здесь нет уязвимости как таковой. В чём она, если формально? Пакет ведь может тянуть другие пакеты, вот он и тянет. Если поставить какой-то лимит (не более N пакетов), то либо начнутся жалобы на то, что лимит маленький, либо его тоже как-то обойдут.
«уязвимость» в том, что если проект почему-то требует слишком много оперативки/ресурсов, то npm ломается. Вместо «npm ломается» должен быть внятный memory limit error. А уж почему он требует слишком много — можно разбираться потом. И можно даже забанить автора «злого» пакета за abuse системы.
Так ведь есть heap out of memory.
V8 под капотом лимитируется в 1.7 Гб
Он не должен ломать ничего в системе пакетов. Кто добавил к себе, тот и получил понятную ошибку при сборке или добавлении (системы могут себя вести по разному) и ушел разбираться со своими зависимостями. Проблемы нет.
А блокировка удаления всего это вообще хорошо и правильно. Мавен так живет. Всем удобно. Выкладывайте пакеты аккуратнее, чтобы потом не позориться пятыми патчами.
Давно уже нет лимита на 1.7, на 64-битных системах лимит может случиться только если полезут баги. Подрбней здесь.
Т.е. никого не напрягло, что GitHub задеплатформил проект только потому, что NPM написан левой пяткой?
Лучше в этой новости - запрет удаления пакетов. Очень бесит когда находишь какой-то пакт, а автор оказывается его уже удалил
Пакет Everything, охватывающий зависимостями все пакеты в репозитории NPM, случайно чуть не сломал NPM