Разработчики репозитория Python-пакетов PyPI (Python Package Index) объявили о внедрении поддержки механизма цифровой аттестации для проверки подлинности опубликованных пакетов, которая пришла на смену верификации с использованием PGP-подписей. Ключевым отличием аттестации является то, что публикация пакета заверяется не разработчиком, а третьим лицом (каталогом пакетов) после подтверждения достоверности публикации через внешнего провайдера OpenID Connect (например, после проверки, что публикуемый пакет соотносится со связанным с ним репозиторием на GitHub или GitLab).
Система аттестации устраняет недостатки, свойственные механизму верификации по PGP-подписям, который ранее был объявлен в PyPI устаревшим. Данное решение принято из-за проблем с проверкой принадлежности разработчикам открытых PGP-ключей, используемых для проверки цифровых подписей - из 1069 PGP-ключей, использованных с 2020 года для формирования подписей в PyPI, 29% открытых ключей отсутствовали на крупных публичных серверах ключей, а 35% ключей оказалось невозможно подтвердить в ходе аудита. При этом подтверждённые 36% PGP-ключей охватывали лишь 0.3% от всех подписанных файлов.
В новой системе используемые для заверения пакетов подписи создаются с использованием короткоживущих эфемерных ключей, генерируемых на основе полномочий, подтверждённых провайдерами OpenID Connect. В момент генерации ключей, необходимых для создания цифровой подписи, разработчик идентифицирует себя через провайдера OpenID, подтверждающего его связь с основным проектом. Инфраструктура для цифровой аттестации построена при помощи системы Sigstore и инструментария in-toto Attestation Framework.
Из достоинств аттестации называется отсутствие привязки к постоянным PGP-ключам - утеря или компрометация закрытого ключа разрушает доверие к созданным на его основе подписям, в то время как при аттестации подпись формируется в привязке к токену, подтверждающему полномочия в момент размещения пакета и связь пакета с основным репозиторием с кодом. Например, при публикации пакета, подготовленного через GitHub Action, аттестация определяет верифицируемую и подтверждённую связь между размещаемым в PyPI файлом, репозиторием, workflow-процессом и хэшем коммита на основе которого сформирован пакет.
Для отслеживания подлинности пакетов и выявления возможных компрометаций формирующих пакеты проектов и самого PyPI применяется публичный централизованный лог, для обеспечения целостности и защиты от искажения данных задним числом в котором задействована структура "дерево Меркла" (Merkle Tree, каждая ветка верифицирует все нижележащие ветки и узлы благодаря древовидному хешированию). По сути аттестация сводится к ведению лога заверенных цифровой подписью утверждений, охватывающих такие сведения, как хэш от содержимого пакета и данные об источнике пакета, например, репозитории из которого собран пакет.
Внедрение аттестации находится на начальном этапе - из 360 наиболее часто загружаемых пакетов в PyPI аттестация задействована для 21 пакета. Аттестация пока применяется только на стороне PyPI, а проверки устанавливаемых пакетов на основе предоставляемого лога ещё не интегрированы в клиенты, такие как pip и uv (для pip ведётся разработка плагина, добавляющего логику проверки в команду "pip install"). Без поддержки на стороне клиентов проверки ограничиваются взаимодействием PyPI с источниками публикации пакетов, но не позволяют пользователям, устанавливающим пакеты, верифицировать PyPI.
Дополнительно можно отметить выявление в каталоге PyPI вредоносного пакета "fabrice", который при помощи тайпсквотинга (назначение похожих имён, отличающихся отдельными символами, например, exampl вместо example, djangoo вместо django, pyhton вместо python и т.п.) маскировался под популярную библиотеку "fabric", насчитывающую 201 миллионов загрузок (7 миллионов загрузок за прошлый месяц). Вредоносный пакет оставался незамеченным с 2021 года и с тех пор был загружен более 37 тысяч раз.
Пакет "fabrice" повторял базовую функциональность исходной библиотеки и дополнительно включал код для выявления и отправки на внешний хост ключей для доступа к AWS (Amazon Web Services), установки бэкдора и выполнения определённых скриптов. Активация вредоносных компонентов производилась в Linux и Windows. В Linux связанные с вредоносной активностью файлы загружались в каталог ~/.local/bin/vscode.