Terrarium Assembler — кроссплатформенные Python приложения с аудитом сборки (Стас Фомин, OSSDEVCONF-2023) — различия между версиями

Для решения этих проблем мы разработали серию open-source проектов «Terrarium Assembler» (TA).

В отличие от прошлого доклада, поверхностно посвящённого решаемым проблемам и преимуществам подхода, в
этом мы постараемся кратко и концептуально, не дублируя документацию
([https://github.com/belonesox/terrarium_assembler/blob/master/README_RU.md]), рассказать «как это
работает» на архитектурно-техническом уровне, с подсветкой наверное наиболее важной для российской аудитории части —
как использование проекта помогает проходить сертификации.
</blockquote>

{{VideoSection}}

{{vimeoembed|901720250|800|450}}
{{youtubelink|}}
|aJETbnNxVIo}}
== Thesis ==

Текущая версия на 14:09, 16 июня 2024

Докладчик

Стас Фомин

Python-стек общепринят для прототипирования и разработки высокотехнологических приложений (оптимизация, машинное обучение, симуляции, распознавание текста, …, любая научная магия). Однако нетривиально превратить прототип в кроссплатформенное приложение, работающее на всех Windows- и Linux-системах, включая сертифицированные российские Линуксы, не используя запрещённые регулятором приёмы типа классических Linux-контейнеров.

Ещё сложнее пройти аудит и сертификацию, избавившись от интерпретаторов в поставке и предъявив воспроизводимый способ сборки каждого бинарного файла, имеющегося в дистрибутиве, из исходных кодов. Даже если брать только Linux, то пересборка «всего лишь Python-библиотек» с произвольным выбором версий сложнее «полной пересборки Linux», где эти версии зафиксированы, ведь при этом всё равно приходится сутками пересобирать базовый уровень библиотек, от gcc до библиотек линейной алгебры.

Важно обеспечить, чтобы технические проблемы сертификационной сборки не тормозили разработку или экспериментирование с выбором библиотек и их версий.

Для решения этих проблем мы разработали серию open-source проектов «Terrarium Assembler» (TA).

В отличие от прошлого доклада, поверхностно посвящённого решаемым проблемам и преимуществам подхода, в этом мы постараемся кратко и концептуально, не дублируя документацию ([1]), рассказать «как это работает» на архитектурно-техническом уровне, с подсветкой наверное наиболее важной для российской аудитории части — как использование проекта помогает проходить сертификации.

Видео

on youtube

Thesis

\projecturl{[2], [3], [4]} \maketitle

Python уже давно самый удобный язык для прототипирования и разработки высокотехнологических приложений, ибо сейчас в нём есть «батарейки» практически для всех областей научной разработки (криптография, символическая алгебра, алгоритмы оптимизации, машинное зрение, AI/ML), и при этом самый короткий путь от набросков алгоритмов в Jupyter-ноутбуках до работающего для пользователей web-сервиса.

Однако обычным путём такие приложения нельзя сделать кроссплатформенными и сертифицированными российскими регуляторами — требуется и отсутствие интерпретируемого кода, и контролируемая сборка из исходников всех бинарных файлов (см., например. ДСП-шные руководства ФСТЭК).

Нельзя (или, скажем, неразумно до безумия) использовать:

• Python-деплой в виде как-то опакеченных виртуальных окружений — нет, не кроссплатформенно

(виртуальные окружения привязаны к версиям python, не говоря уж про версии GCC), нельзя тащить что-то на интерпретируемых языках (регуляторы), в любом случае надо пересобирать каждый бинарник.

• Системные пакеты самих ОС — сертифицированные Линуксы — это только

базовые пакеты (несколько тысяч пакетов по сравнению с сотней тысяч пакетов «нормального» Linux, и там нет ничего высоконаучно-питонового. Плюс необходимость собирать и тестировать отдельные версии под каждую версию целевой системы, с разной пакетной базой, политиками, форматами пакетов и даже версиями GCC. «Десятки сертифицированных Линуксов» с анемичной пакетной базой, и оригинальными доработками — это не достижение российской индустрии, а вечная боль всех поставщиков прикладных решений, минное поле для тестирования ошибок в поддержке стандартов и протоколов. Увы, шанс в обозримом будущем дождаться «единый сертифицированный российский Линукс» с пакетной базой уровня Debian/Fedora — пренебрежимо мал.

• Линукс-контейнеры docker/podman — могли бы быть (и может ещё будут) решением, но

пока они, с одной стороны, отсутствуют в большей части сертифицированных дистрибутивов, а с другой стороны, являются настолько запрещёнными, что даже наличие где-то среди исходников файла формата сборки Docker-контейнера действует как красный флаг для сертификационной лаборатории. Аналогично с подходами типа snap/flatpack/appimage.

И это не говоря уже про Windows, где совсем отдельный мир для сборки и публикации приложений, хотя там гораздо лучше с бинарной совместимостью.

Наш подход, обеспечиваемый серией проектов «Terrarium Assembler» (TA), следующий:

• Разработчики совершенно свободно используют удобные им дистрибутивы для разработки будь то Windows

или Linux, разрабатывая кроссплатформенный Python-код, используя все нужные им библиотеки.

• Достаточно быстро с помощью TA можно собрать «отладочную версию», проверив, что различные проекты

имеют совместимые зависимости по библиотекам, что проходят тесты и т.\,п.

• Если тесты в порядке, то более длинный путь собирает скомпилированный дистрибутив, где Python-код компилируется в Cи-шный код с помощью Nuitka, затем компилируется в бинарный код, и всё это собирается в «переносимую папку со всеми зависимостями и ld.so загрузчиком», работающую под любыми Линуксами. Рекомендуемый вендорами российских Линуксов путь «ладно, берите нужные библиотеки, но glibc-то у нас годная» [5] — увы, не работает, когда нужна поддержка старых дистрибутивов, поэтому надо брать всё, включая «ld.so».
• Аналогично, и чуть легче с некой заменой исходников, можно собрать проект и для Windows, тоже «переносимая папка».
• Опакечивается в любой требуемый формат (DEB/RPM/ISO/ MSI/EXE с инсталлятором), и запускаются финальные тесты с инсталляцией на стенды.
• И самый длинный путь, если вышеперечисленной сборки прошли тесты — это сборка для аудита, когда дополнительно происходит
  • Сборка «Системной платформы» (может длиться сутки) — перекомпиляция RPM-спеков всех системных библиотек (от libc до питоновых), так или иначе попадающих в дистрибутив.
    • При этом можно собрать не только библиотеки, но и все нужные сервисы и утилиты (включая базы данных, вебсерверы и т.п.).
    • Также при этом можно собрать отсутствующие системные RPM-пакеты на основе своих SRPM.
    • Для Windows используются спеки сборки системы CONAN.
    • Сборка «Python-библиотек» нужных версий из исходников. Это приходится делать отдельно, т.,к. нужных версий скорее всего нет в «Системной платформе».
  • Кроме Python-проектов можно собирать также и Go и C++ проекты и модули, но со сборкой Go-проектов и так нет проблем («go download/go build»), и в целом проект ориентирован именно на решение выкатки Python-решений.

В результате, удаётся добиться и быстрой разработки, и честного аудита воспроизводимой сборки, выполняемого из фиксированных исходников в «чистой комнате» без доступа интернету и к каким-либо хранилищам артефактов, так, что про каждый бинарный файл известно, из какого исходного кода он получен.

Система была разработана несколько лет назад, презентована [6] на конференции OSSDEVCONF-2021 («Terrarium Assembler — эффективные сборка и распространение высокотехнологичных Python-приложений под различные операционные системы»), но с тех пор постоянно развивалась, в частности:

• Контейнеризирована вся сборка, что позволяет на одной сборочнице собирать разные проекты без риска

«переопыления», и теперь Linux-версией TA можно пользоваться на любом современном Линуксе.

• Поддерживается сборка пакетов всех типов — RPM/DEB/ISO/ MSI.
• Радикально улучшен режим аудит-сборки, по опыту взаимодействия с разными лабораториями сертификации

(«под Минобороны», «под ФСТЭК», …).

• Автоматизирована система минимизации дистрибутива используя strace-анализ выполняемых тестов.
• Моделирование «монорепозитория» в виде отдельных операций над всеми репозиториями отдельных

библиотек проекта.

• Системно решено множество частных проблемных ситуаций.

Примечания и ссылки