Комментарии 46
Хм… чтоб мы делали без вашего комментария!
Ключ тяжелее украсть, чем аккаунт на популярном сайте.
Очевидно, что npm — не дистрибутив и поэтому владелец npm умается проверять каждого человека, желающего опубликовать свою библиотеку. Но и эта проблема решается сетями доверия.
Просто об этом никто не подумал когда создавал репозиторий. И, кстати, с докером та же проблема.
Почему сразу "никто не подумал когда создавал репозиторий", вы когда разрабатываете систему для двух с половиной человек тоже начинаете с сети доверия? Все хорошо работало, на энтузиазме и благих намерениях, но пришло время столкнуться с реальностью. Хотя, да, идея с сетями доверия выглядит своевременной.
Уверен, что у 90% мейнтейнеров ключ лежит в обычном файле в ~/.gpg и украсть его не сложней, чем украсть пароль
С другой стороны, тогда нужен и ключ и пароль к нему, а без ключа — только пароль. То есть ключ уже дает два фактора защиты (доступ к файлу и знание пароля) вместо одного
Конечно, если владелец не хранит пароль рядом с ключом, а держит его в голове.
оффтоп: фото - огонь
В принципе вариантов не так уж много. Опасность не столько в фишинге крупных пакетов, сколько в распространении подобного кода в виде зависимости. Встает вопрос, каким образом можно ускорить и упростить процесс ревью кода. В данный момент просмотреть код пакета перед загрузкой невозможно и это самая большая опасность, ведь код в пакете может не соответствовать коду на гитхабе, да еще и транспилирован в трудночитаемое месиво.
В пакетном менеджере DUB именно так и сделано. Чтобы выпустить новую версию пакета — достаточно добавить новый semver git tag. Это гораздо удобней, чем всякие npm (pre)publish.
Определение того, содержит ли пакет нечто вредоносное при публикации, конечно, эквивалентно приостановке работы, сделать мы этого не можем.
Так проверяли бы не в момент публикации, а после. Если после проверки выяснится, что пакет безопасный — вешали бы шильдик «The package is safe.» А разработчик пусть сам решает, стоит рисковать и устанавливать ещё не проверенный пакет, или стоит подождать когда бот доберётся до него.
Вопрос в том, как бот будет проверять пакет? Что именно он будет искать? Мне кажется, что при автоматической проверке шильдик будет давать ложное чувство безопасности и в итоге сделает систему крайне уязвимой перед новыми атаками.
Хотя и можно создать 2 пакета: для отправки запросов (безопасный) и отправщик запросов.
Идеального решения нет, но вопрос ввода шильдиков это вопрос времени, имхо.
Есть еще компилируемые пакеты, а компанды npm могут содержать инструкции написаные на bash (т.е. потенциально инструкцию на любом языке). Cкрипт на JS может вызывать curl и т.п.
Так что вариант со срабатыванием на определенный пакет, защитит от очень узкого класса атак. Шильдик должен использоваться не раньше, чем будет достигнут минимально допустимый уровень безопасности.
эквивалентно приостановке работы
equivalent to the halting problem
Но это "проблема останова", а не "приостановка работы".
В apt/yum есть source list который указывает какой пакет из какой репы тянуть пока туда всякого бреда не добавить — все ок.
В composer пакеты состоят из пары автор+пакет который не позволит без pull request человеку посередине как-либо заменить пакет без авторов. и пока вы доверяете автору и проверяете его пакеты — все ок.
а тут — одна очепятка и вы труп.
Не очень понял как composer защищает от сквоттинга пакетов с опечатками в названии. Что мешает завести там пакет с именем "lavarel" например?
имя пакета = имя автора/имя пакета
в случае с laravel это laravel/laravel
добавить свой пакет с laravel может любой но вот в вашем случае он будет выглядеть как justboris/laravel
это немного решает проблему сквотинга.
Да можно назвать пакеты lalavel/lalavel но тогда придется либо подделывать все его зависимости от автора laravel а их может быть довольно много. либо затягивать оригинальный пакет и самой папке vendor будет и laravel и lalavel что заставит задуматься адекватного разраба что он затянул что-то не то.
Также такой подход позволяет строить более адекватную сеть доверия так как имя автора зашито в пакете и одновременно позволяет создать несколько одинаковых конкурирующих пакетов с одинаковым именем от разных авторов.
А вы действительно смотрите в папку vendor после установки зависимостей?
Точно так же можно сказать и про node_modules, что, если заглянуть в нее, то там будет видно неправильное имя. Но, как правило, никто туда не смотрит.
Как ни странно я понимаю почему туда никто не смотрит, для меня такого сурового backend php человека найти что-то в этой папке просто нереально. простейший проект содержит +100500 элементов.
Если бы сгруппировать её как в composer хотя бы по авторам — думаю она была бы куда компактнее и просматривать её было бы куда удобнее. Еще обилие модулей из 1.5 файла и 50-100 строк вроде того-же скандального leftpad который любой backend человек напишет за 20 минут тоже играет свою роль.
Возможно это просто вопрос религии но в php есть смысл создавать, поддерживать и использовать библиотеку только тогда когда функционал в ней "чуть сложнее" чем добавление 20 пробелов в начало строки.
Что касается vendor то раз в неделю я там точно бываю (если это только не двух недельный отпуск)
Как ни странно я понимаю почему туда никто не смотрит
Вообще да, структура node_modules просто отвратительная, а вложенность зависимостей — крайне дурацкая идея. Я уж молчу, что иногда вложенность такая, что винда не может работать с этой директорией (например удалить ее). Конечно, это больше кривизна винды, чем ноды, но все-равно.
Так зависимости же складываются в плоский список, если это возможно. Если А и В зависят от С одной версии, то С попадет на один уровень с A и В.
Или вы не об этом?
Мы тут скорее о том что открыв node_modules в типичном проекте ты увидишь папку с +100500 папок внутри и по сути структура действительно плоская.
1 папка — 1 библиотека
пример:
- 7zip-bin
- 7zip-bin-linux
- ansi-align
- ansi-regex
- ansi-styles
в composer 2 уровня вложенности — автор/библиотека
пример:
- laravel/framwork
- laravel/passport
- symfony/console
- symfony/debug
- symfony/process
- symfony/routing
- symfony/yaml
- symfony/var-dumper
итог — вместо 8 папок под каждую библиотеку у нас 2 папки авторов с 2 и 6 библиотеками соответственно
В java это дошло до абсурда где папка библиотеки = домен.сайт.проект.автор.библиотека.модуль
Например в maven для того чтобы добраться до самого jar файла библиотеки нужно открыть 3-5 папок.
Ваш аргумент я понял, и с ним я соглашусь. Но TheShock пишет:
а вложенность зависимостей — крайне дурацкая идея
Вот я и не понимаю, вложенность — это хорошо или плохо
Я думаю что он тут скорее о том что node_modules выросла очень сильно и винда с таким количеством папок и файлов тупо не справляется и в итоге без особых извращений папку не удалить.
теоретический лимит ntfs на папку — 4,294,967,295 файлов но на практике уже 10000 файлов вызывают дикие лаги на win7.
В ext4 который нет лимита на папку но есть лимит на количество файлов и папок в принципе и он огромен и в случае надобности его можно внезапно увеличить.
Плюс если папка разрослась до того что лагает в linux есть как минимум 5 способов её удалить но это очень редкая ситуация.
Сама по себе вложенность это не что-то плохое а скорее нечто с чем приходиться жить.
Но TheShock пишет:
Я немного о другом. Вложенность зависимостей — дурацкая идея. Проблема в том, что " в плоский список, если это возможно". Почему-то, очень часто оно не работает. Может дело в зависимостях зависимостей? Я не знаю. Так вот — очень часто их глубина становится слишком большой. Проблема не с количеством файлов, а с тем, что путь к самым глубоким зависимостям такой длинный, что винда не может с ним работать.
Как на меня все модули должны всегда лежать на одной вложености (не важно какой, это может быть как iit предлагает), плюс я бы еще версию добавил, как раз, чтобы любой модуль мог подключить необходимую версию.
laravel/framwork/1.0
laravel/framwork/2.0
laravel/passport/0.1
symfony/console/1.0
symfony/console/1.2
symfony/debug/1.5
речь шла не о зависимосях а о файлах. а файлов куда больше 10.000 причем настолько что пришлось увеличивать лимиты inode на сервере. а проект — обычный финансовый портал внезапно на php и моднутой сумрачными гениями umi cms, естественно без composer а фронт на костылях jquery и scritpaculous.
файлы в основном изображения в новостях. новостей штук 15-20 в день и в каждой от одного до 15 изображений. с 2008 года набралось их очень приличное количество.
естественно при разворачивании папки с изображениями на win7 explorer.exe превращаеться в тыкву.
npm начиная ещё с v3 старается собирать зависимости
То, что старается, а не собирает — это плохо.
Или даже вот такая картинка:
То есть я, конечно, понимаю, что в версии 3 уже получше, чем в версии 2. И что там написано как уменьшить эти проблемы, но ведь можно было сделать лучше. Не «мы пытаемся выровнять, но иногда, конечно, какая-то либа может использоваться 3 раза», а именно сделать, чтобы вложенность всегда была одинаковой и чтобы двух копий одной версии вообще не могло появится.
Вредоносный код в npm-пакетах и борьба с ним