Здравствуйте, dsorokin, Вы писали:

Pzz>>Ну vendoring вроде решает проблему с недоступностью источника...

D>Нет, конечно! Главное, что не решает саму проблему!

Почему? Допустим, тебе нужна библиотека версии 1.1.0. Ты ее вендоришь и получаешь копию в свое дерево исходников. Дальшь даже если оригинал и пропадет, твоя завендоренная копия никуда не денется. В следующий раз оригинал тебе понадобится только когда захочишь версию библиотеки обновить.

D>Скажу банальные вещи, но здесь нужна децентрализация в распространении библиотек, причем децентрализация с элементами той же сертификации или с элементами ответственности мейнтейнеров.

Деценрализация нужна. На самом деле, ей довольно активно занимаются. Но она пока не достигла того уровня, чтобы потеснить общепринятые методы.

D>Примерно так и происходит у дистрибутивов линукса, но для C и C++, а нужно для большего числа языков. Впрочем, мы приехали к тому, с чего начинали в этом чате

Увы, вся эта децентрализация линуха, за редким исключением, сейчас помещается на github.com и gitlab.com.

А что, в расте все загрузки идут через централизованное место? В Go можно прям с гитхаба грузить (с любого git-овского репозитория).

D>Мне кажется, что должно пройти время, которое осудит модель распространения библиотек с единым репозиторием. Они уязвимы по определению. Просто это время еще не пришло, не пришло массовое осознание, хотя первые шаги уже сделаны. Например, были всяко-разные инциденты у того же npm. Ладно, это не нам решать!

npm, похоже, не контролирует ничего. Тот же Go, ему паленую копию внешней библиотеки не подсунешь, он будет против. И автоматического обновления внешней зависимости тоже не происходит, если я привязался к версии 1.1, что переход на 1.2 — это явное действие с моей стороны. Чего там в апстриме творится, автоматически ко мне не попадает.

Я думал, в расте примерно так же.