Что мешает воспроизводимым сборкам на PyPI

· Безопасность
Бретт Кэннон разбирает, чего не хватает экосистеме Python, чтобы независимые стороны могли проверять целостность пакетов на PyPI — и почему это можно сделать почти без усилий со стороны авторов.

cover.svg

Готовя раздел о безопасности цепочки поставок для своей заявки в Python Packaging Council на 2026 год, Бретт Кэннон обратил внимание на заметный пробел: в экосистеме Python до сих пор нет определённого способа выполнять воспроизводимые сборки. Привлекательность этой идеи, по его словам, в том, что реализовать её можно так, чтобы от авторов дистрибутивов (тех, кто загружает sdist- и wheel-пакеты на PyPI) не требовалось никаких дополнительных действий.

Зачем это нужно

Воспроизводимые сборки позволяют независимым третьим сторонам убедиться, что содержимое пакета соответствует исходному коду, из которого он собран. Это даёт шанс обнаружить вмешательство в процесс сборки. Побочный эффект — необходимость фиксировать состав использованного при сборке ПО, что упрощает выявление уже известных скомпрометированных инструментов. Угроза не гипотетическая: атака на SolarWinds стала возможной именно из-за внедрения вредоносного кода в процесс сборки.

Кэннон предостерегает от иллюзии, будто чистые Python-пакеты в безопасности: их тоже создаёт некий бэкенд сборки, и если он скомпрометирован, вредоносный код может оказаться в готовом wheel.

Чего не хватает спецификациям

Первое — нигде не фиксируется, какой именно исходный код использовался. При установке напрямую из репозитория эта информация попадает в файл direct_url.json, но в самих sdist и wheel её нет. Достаточно записывать её в метаданные.

Второе — учёт всех инструментов сборки. Для wheel уже есть механизм SBOM (перечня компонентов ПО), добавленный через PEP 770, делегатом которого выступал сам Кэннон. А вот у sdist аналогичного механизма нет: это обычно просто tarball с файлом PKG-INFO, куда некуда положить дополнительные метаданные. Значит, либо придётся признать, что sdist не годятся для воспроизводимых сборок, либо разрабатывать формат sdist v2.

Воспроизвести саму сборку помогает таблица [build-system] в pyproject.toml: она задаёт точку входа в бэкенд. Если бэкенды научатся фиксировать окружение, в котором работают, всю нужную информацию можно будет собирать в SBOM уже сегодня — без усилий со стороны авторов пакетов, но ценой работы для сопровождающих pip.

Как показать это на PyPI

Чтобы польза доходила и до тех, кто сам ничего перепроверять не хочет, Кэннон предлагает институт доверенных верификаторов. Предприятия, которые и так занимаются подобными проверками, могли бы сообщать PyPI об успешно воспроизведённых пакетах, а платформа — отмечать: «этот файл независимо воспроизведён такой-то стороной». Установщики даже могли бы предпочитать проверенные сборки.

При этом автор подчёркивает: подход не должен никого стыдить. Воспроизводимость — приятный бонус, а не требование. Это как возможность заявить, что проект соответствует первому уровню SLSA: кому-то приятно, но отсутствие такой отметки — не упрёк.


Источник: Lobsters

Комментарии

Войдите, чтобы комментировать.

  • Пока нет комментариев.