Страница 1 из 1

О менеджерах зависимостей

Добавлено: 29.03.2017 13:56
Bizdelnick
Мне никогда не нравились сборочные системы, позволяющие жёстко привязаться к конкретной версии какой-то зависимости. Наверное, одной из первых таких, и точно одной из самых популярных является Maven. И вот свежая новость о том, к чему это приводит. TL;DR: исправленная уязвимость в библиотеке приводит к тому, что все проекты, где забыли поднять версию зависимости, остаются уязвимыми. Если таким образом уязвимость распространяется рекурсивно на другие библиотеки и фреймворки, в итоге она попадает в программы, зависящие от уязвимой библиотеки только опосредованно, для разработчиков которых может вообще оказаться полной неожиданностью, что данная уязвимость может иметь к ним какое-то отношение. Итог — куча дырявого софта, использующегося повсеместно, в данном случае — 2600 только открытых проектов. От взлома пострадало, в частности, муниципальное транспортное агентство Сан-Франциско — год спустя после обнародования информации об уязвимости.
Вот так вот, дорогие любители maven/pip/node/godep/cargo/что-там-вы-используете.

Re: О менеджерах зависимостей

Добавлено: 29.03.2017 23:35
SLEDopit
Bizdelnick писал(а):
29.03.2017 13:56
Вот так вот, дорогие любители maven/pip/node/godep/cargo/что-там-вы-используете.
А какие альтернативы? Вместо оттестированной связки компонентов выпускать на продакшн сборку "мне повезёт" и надеяться, что в момент деплоя соберётся что-нибудь работоспособное?

Re: О менеджерах зависимостей

Добавлено: 30.03.2017 00:23
Kopilov
Maven, хотя бы, позволяет указать нечто вроде 1.2.* или >= 1.2.5
Вот у нас сейчас на работе Ceylon Herd -- так там можно только одну конкретную версию указать, никаких диапазонов. И разработчики (не наши, а Ceylon-а) говорят: это не баг, а фича.
Кстати, если не ошибаюсь, данная багофича -- одна из причин, по которой JetBrains, вдохновившись Ceylon-ом, запилили себе Kotlin, а не стали использовать сей продукт RedHat-а

Re: О менеджерах зависимостей

Добавлено: 30.03.2017 12:22
Bizdelnick
SLEDopit писал(а):
29.03.2017 23:35
А какие альтернативы? Вместо оттестированной связки компонентов выпускать на продакшн сборку "мне повезёт" и надеяться, что в момент деплоя соберётся что-нибудь работоспособное?

Тут проблема комплексная. Именно из-за того, что в продакшне принято делать привязки к конкретным версиям библиотек, разработчики библиотек зачастую не парятся вопросами обратной совместимости. Вся система порочна в корне, любая попытка найти решение будет костылём. Правильнее было бы делать, как в go, где возможна привязка только к последней версии из дефолтной ветки VCS. Но из-за быдлокодеров такая система не прижилась, изобрели костыль godep и суют его везде где надо и не надо.

Kopilov писал(а):
30.03.2017 00:23
Maven, хотя бы, позволяет указать нечто вроде 1.2.* или >= 1.2.5

Да почти все позволяют. Только мало кто так делает по факту.