Вы не должны доверять своим зависимостям Composer

Перевел поиск на php, теперь он в модуле и с ним можно заниматься. Сам поиск требует некоторых зависимостей и необходимо было использовать и Composer.

В основном его хвалят, иногда предупреждают, как в этой статье (Simon Hamp):

Вы не должны доверять своим зависимостям Composer

У меня есть небольшой подарок для вас: вы наслаждаетесь заслуженным перерывом в работе! Однако во время вашего отпуска ваше критически важное веб-приложение было захвачено какой-то гнусной третьей стороной и повсеместно подвергается злоупотреблениям — данные клиентов похищаются, ключи и пароли к внутренним системам утекают, а ваши базы данных повреждаются и удалены в попытке саботировать бизнес вашей компании.

Конечно, это довольно экстремальный кошмарный сценарий, но он может стать реальностью, когда вы полагаетесь на зависимости, поступающие из ненадежных источников. Мы уже видим этот потенциал в NPM.

Если вы разработчик PHP, нет абсолютно никаких причин, по которым это не может относиться и к зависимостям Composer!

Позвольте мне прояснить, прежде чем мы пойдем дальше: я очень благодарен за Composer. Я использую его почти каждый день. Я считаю, что это неизмеримо изменило лицо PHP-разработки к лучшему. Но мы не должны слепо доверять коду, который он нам поставляет.

«Неа! Композитор в безопасности!»

Извините, что разорвал ваш пузырь, но Composer небезопасен. Он страдает от той же слабости, что и все менеджеры пакетов: он позволяет любому склонному к ошибкам и ленивому человеку с некоторыми способностями к кодированию публиковать пакет неизвестной надежности в общедоступном каталоге пакетов без каких-либо гарантий относительно безопасности их кода.

В качестве дополнительного бонуса, будь то садистская шутка или, может быть, это просто свершившийся факт, пакеты могут ссылаться на другие пакеты (тут этот случай. прим.), на которые они полагаются, тем самым создавая каскадный граф подверженности ошибкам зависимостей, каждый из которых может быть легко загружен на ваш сервер несколькими нажатиями клавиш и щедрая порция полного блаженства.

На практике это означает, что код, на который вы полагаетесь, написанный людьми, которым вы «доверяете» (небрежно), все еще может быть невольным троянским конем, который несет подлого грека через черный ход (так сказать).

Время приключений

Итак, допустим, вам нравится использовать Laravel. Мне очень нравится Laravel. Я ничего против этого не имею, я не называю это конкретно хорошим или плохим примером. Это просто для примера.

Итак, Laravel. Вы решаете настроить приложение Laravel так же, как и при любой другой установке Laravel, которую вы сделали. Прежде чем вы это узнаете, целая куча стороннего кода проникнет на ваш компьютер.

Ни вы, ни Тейлор Отвелл не знали , что одна из глубоких зависимостей Laravel была скомпрометирована хакерами.

И т.д. Но пришлось к нему прибегнуть… и код проекта увеличился почти в 10 раз. Надо как-то искать, работать с морфологией, вот и поставил.

Репозиторий GitHub подключен к сервису https://www.codacy.com/, которые имеет тенденцию ругаться, если что-то не то сделаешь.

При этом обновлении: 407 changed files with 544,472 additions and 291 deletions, если честно, ожидал огромного обвала и…  — это первый случай, когда он почти не отреагировал.

Удивительно! Столько строк кода и так всё достойно.

➕

P.S. пишу сразу, сейчас смотрю возможность перейти для участников на адрес @NICKNAME. Т.е. был /u/NICKNAME станет /@NICKNAME. Как и обращение тут через @.