Мне никогда не нравились сборочные системы, позволяющие жёстко привязаться к конкретной версии какой-то зависимости. Наверное, одной из первых таких, и точно одной из самых популярных является Maven. И вот свежая новость о том, к чему это приводит. TL;DR: исправленная уязвимость в библиотеке приводит к тому, что все проекты, где забыли поднять версию зависимости, остаются уязвимыми. Если таким образом уязвимость распространяется рекурсивно на другие библиотеки и фреймворки, в итоге она попадает в программы, зависящие от уязвимой библиотеки только опосредованно, для разработчиков которых может вообще оказаться полной неожиданностью, что данная уязвимость может иметь к ним какое-то отношение. Итог — куча дырявого софта, использующегося повсеместно, в данном случае — 2600 только открытых проектов. От взлома пострадало, в частности, муниципальное транспортное агентство Сан-Франциско — год спустя после обнародования информации об уязвимости.
Вот так вот, дорогие любители maven/pip/node/godep/cargo/что-там-вы-используете.
О менеджерах зависимостей (и их вреде)
Модератор: Модераторы разделов
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
О менеджерах зависимостей
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |
Спасибо сказали:
Re: О менеджерах зависимостей
А какие альтернативы? Вместо оттестированной связки компонентов выпускать на продакшн сборку "мне повезёт" и надеяться, что в момент деплоя соберётся что-нибудь работоспособное?Bizdelnick писал(а): ↑29.03.2017 13:56Вот так вот, дорогие любители maven/pip/node/godep/cargo/что-там-вы-используете.
UNIX is basically a simple operating system, but you have to be a genius to understand the simplicity. © Dennis Ritchie
The more you believe you don't do mistakes, the more bugs are in your code.
The more you believe you don't do mistakes, the more bugs are in your code.
Re: О менеджерах зависимостей
Maven, хотя бы, позволяет указать нечто вроде 1.2.* или >= 1.2.5
Вот у нас сейчас на работе Ceylon Herd -- так там можно только одну конкретную версию указать, никаких диапазонов. И разработчики (не наши, а Ceylon-а) говорят: это не баг, а фича.
Кстати, если не ошибаюсь, данная багофича -- одна из причин, по которой JetBrains, вдохновившись Ceylon-ом, запилили себе Kotlin, а не стали использовать сей продукт RedHat-а
Вот у нас сейчас на работе Ceylon Herd -- так там можно только одну конкретную версию указать, никаких диапазонов. И разработчики (не наши, а Ceylon-а) говорят: это не баг, а фича.
Кстати, если не ошибаюсь, данная багофича -- одна из причин, по которой JetBrains, вдохновившись Ceylon-ом, запилили себе Kotlin, а не стали использовать сей продукт RedHat-а
- Bizdelnick
- Модератор
- Сообщения: 20795
- Статус: nulla salus bello
- ОС: Debian GNU/Linux
Re: О менеджерах зависимостей
Тут проблема комплексная. Именно из-за того, что в продакшне принято делать привязки к конкретным версиям библиотек, разработчики библиотек зачастую не парятся вопросами обратной совместимости. Вся система порочна в корне, любая попытка найти решение будет костылём. Правильнее было бы делать, как в go, где возможна привязка только к последней версии из дефолтной ветки VCS. Но из-за быдлокодеров такая система не прижилась, изобрели костыль godep и суют его везде где надо и не надо.
Да почти все позволяют. Только мало кто так делает по факту.
Пишите правильно:
в консоли вку́пе (с чем-либо) в общем вообще | в течение (часа) новичок нюанс по умолчанию | приемлемо проблема пробовать трафик |