Vendoring зависимостей

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

В reuse-less-software этот подход рассматривается как защита от атак на цепочку поставок (supply-chain attacks). Пакетный менеджер, автоматически скачивающий зависимости при каждой сборке, одновременно служит и каналом их автоматического распространения: когда upstream-пакет скомпрометирован, все зависимые проекты подтягивают заражённую версию при следующем запуске CI, и зараза "распространяется со скоростью лесного пожара, настолько быстро, насколько runner'ы CI успевают её исполнять". Vendoring перерезает этот канал. Скомпрометированный upstream-релиз не попадёт к вам, пока вы осознанно не скопируете новый исходный код, не проверите его и не закоммитите. Каждый vendored-пакет становится противопожарной полосой - атака останавливается на границе каждого репозитория, который решил не затягивать обновление.

Та же самая граница мешает автоматически распространяться исправлениям ошибок и патчам безопасности. Автор аргумента соглашается с этим компромиссом: если исправление действительно важно, вы сами пойдёте его искать, а если не ищете - скорее всего, оно не так уж критично. Это тот же компромисс, на который идут cooldown'ы зависимостей, только доведённый до предела: cooldown задерживает автообновления на несколько дней, а vendoring останавливает их полностью, пока не вмешается человек.

Эффект второго порядка: наглядность

Vendoring повышает видимую цену зависимости. "Библиотека на 200 строк", которая на самом деле приносит 50 000 строк закоммиченного исходного кода, сразу бросается в глаза, когда лежит прямо в дереве проекта - чего никогда не произойдёт, если она скрыта за одной строчкой в манифесте. Утверждается, что такое мягкое сопротивление подталкивает к более плоским и компактным деревьям зависимостей: источник надеется сократить типичное число зависимостей "с 200-300" до "максимум 2-3", поскольку каждое добавление теперь требует явных затрат на проверку и коммит кода.

Недостатки

Отсутствие автоматической транзитивной дедупликации. Если и библиотека A, и библиотека B vendor'ят библиотеку Z, у вас будет две копии, и их объединение потребует ручной работы вместо того, чтобы резолвер сделал всё сам. Размер репозитория растёт, хотя автор утверждает, что диск стоит дёшево, а время сборки не меняется, так как этот код всё равно пришлось бы компилировать.

Предельный вариант: Nix/Guix

Если довести идею до конца, vendoring превращается в полностью специфицированное окружение сборки, где каждый входной компонент зафиксирован и адресуется по содержимому (content-addressed) - именно так уже устроены Nix и Guix. Автор источника считает это логической конечной точкой: воспринимать "окружение сборки" как нечто, что нужно полностью специфицировать, а не принимать как данность. Фиксация каждого входного компонента делает сборки воспроизводимыми, поэтому vendoring и воспроизводимость ведут к одной и той же цели.

Связанные страницы

• reuse-less-software - исходный аргумент для этой страницы
• supply-chain-security - класс атак, от которого защищает vendoring
• open-source-security-astral - cooldown'ы зависимостей как более мягкий вариант той же идеи
• reproducible-builds - фиксация всех входных данных как общая основа
• manylinux - сборка wheel'ов для поставки самодостаточных бинарных артефактов