Семейства платформ и переносимая модель сборки
Версия: 0.1
1. Назначение
Любая система семейства Unix строится одной и той же последовательностью решений. Различаются только словарь, формат пакетов и требования к привилегиям. Документ определяет эту последовательность как переносимую модель, отображает её на каждое семейство платформ и формулирует контракт, которому обязан удовлетворять адаптер, чтобы быть допущенным в службу сборки систем.
Модель существует ради того, чтобы спецификация выражала намерение — киоск с усилением защиты, брендированный рабочий стол, подписанный образ устройства целевого назначения, — а механику предоставлял адаптер. Там, где намерение нельзя выразить переносимо, платформозависимая часть указывается явно, а не скрывается.
2. Канонический конвейер сборки
| Этап | Название | Обязательство |
|---|---|---|
| S1 | Разрешение спецификации | развернуть профиль, базу и переопределения в одно эффективное каноническое описание |
| S2 | Фиксация срезов источников | привязать каждый источник к неизменяемому состоянию архива и аутентифицированному корню доверия |
| S3 | Расчёт замыкания зависимостей | вычислить точный набор входов с версиями и хеш-суммами; вместе с S1–S2 это даёт фиксацию входов (lock) |
| S4 | Первичное развёртывание | создать минимальный корень из аутентифицированных входов либо, для систем на основе исходного кода, собрать инструментальную цепочку |
| S5 | Наполнение | установить намеченное содержимое либо собрать world и ядро в промежуточное дерево |
| S6 | Оверлей | наложить файлы, брендирование, политику и конфигурацию, принадлежащие производителю |
| S7 | Конфигурирование | выполнить объявленные хуки; задать идентичность, значения по умолчанию, пользователей, службы и политику безопасности |
| S8 | Сборка загрузочного комплекта | ядро, начальный ramdisk, загрузчик, унифицированные образы, входные данные для измерений |
| S9 | Материализация | построить файловые системы, разделы и распространяемые контейнеры: образ, диск, архив, набор пакетов |
| S10 | Аттестация и подпись | манифест, состав продукта (SBOM), происхождение, хеш-суммы и подписи |
Через весь конвейер проходят два контрольных этапа:
- V1 — офлайн-проверка, после S9: всё, что можно проверить чтением произведённых артефактов.
- V2 — динамическая проверка, после S10: проверки загрузки, обновления и отката в среде с прошивкой, а также на эталонном оборудовании до общей доступности.
Контракты этапов:
- S1–S3 MUST быть свободны от побочных эффектов и MUST выполняться без сборки. Именно возможность получить и изучить lock без сборки делает возможными оценку стоимости, проверку изменений и проверку политик до того, как потрачены ресурсы.
- S4–S9 MUST выполняться внутри границы изоляции, определённой
SCF-BLD-002. - S10 MUST NOT выполняться внутри границы сборки. Ключи подписи никогда не
попадают в среду сборки (
SCF-CRY-003).
3. Переносимая модель сущностей
| Переносимая сущность | Значение |
|---|---|
| Источник (origin) | именованное аутентифицированное место, откуда поступают входы |
| Фиксация среза (pin) | неизменяемое состояние источника в определённый момент времени |
| Компонент | одна единица устанавливаемого содержимого |
| Выборка (selection) | запрошенный набор компонентов, по возможности выраженный через намерение |
| Замыкание зависимостей (closure) | разрешённый набор, включающий зависимости, с версиями и хеш-суммами |
| Оверлей (overlay) | файлы производителя, размещаемые в дереве |
| Хук (hook) | код производителя, выполняемый на определённом этапе |
| Разметка (layout) | разделы, файловые системы и их параметры |
| Загрузочный комплект (boot set) | ядро, начальный ramdisk, загрузчик и их подписи |
| Контракт установщика | механизм и файл ответов, устанавливающие систему на целевую машину |
| Манифест | машиночитаемое описание произведённого |
| Аттестация | подписанное доказательство того, как это было произведено |
3.1 Отображение на семейства
| Переносимая сущность | deb | rpm | apk | FreeBSD | OpenBSD | NetBSD | illumos | Nix / Guix | Yocto / Buildroot |
|---|---|---|---|---|---|---|---|---|---|
| Источник | sources.list / deb822 .sources | baseurl в .repo | /etc/apk/repositories | конфигурация репозитория pkg | зеркало + путь к наборам | pkgsrc + путь к выпуску | издатель IPS | substituter / канал | SRC_URI, git слоя |
| Фиксация среза | служба срезов архива | неизменяемый compose или частный срез | у upstream нет; зеркало производителя | ветка выпуска + срез репозитория pkg | тег выпуска | тег выпуска | метка времени издателя | ревизия flake.lock / коммит канала | коммит слоя |
| Компонент | .deb | .rpm | .apk | .pkg (а с pkgbase — и сама база) | tarball набора | tarball набора | FMRI в IPS | derivation | рецепт |
| Выборка | задача, метапакет, список пакетов | группа comps, пакеты blueprint | apks= в профиле | список pkg, ключи src.conf | список наборов | список наборов | список пакетов | модуль / манифест | IMAGE_INSTALL |
| Замыкание | вывод решателя apt | вывод libsolv | вывод решателя apk | вывод решателя pkg | фиксированный набор | фиксированный набор | решатель IPS | граф derivation | граф задач |
| Оверлей | includes.chroot | файлы kickstart, кастомизации образа | apkovl | каталог оверлея poudriere | siteXX.tgz | staging с учётом METALOG | действия манифеста | файлы модуля | ROOTFS_POSTPROCESS |
| Хук | хуки chroot | %post, скрипт postprocess | .post-install | скрипты pre/post образа | install.site | скрипты postinstall | актуаторы; установочных сценариев нет по замыслу | скрипт активации | команда postprocess |
| Разметка | этап сборки образа | этапы разделов | профиль образа | тип poudriere image | шаблон disklabel | цели образов build.sh | distro constructor | image.repart / тип образа | kickstart wic |
| Загрузочный комплект | подписанные shim, загрузчик, пакеты ядра | подписанные shim, загрузчик, пакеты ядра | варианты ядра | loader.efi | bsd, bsd.rd | наборы ядра | boot archive | унифицированные образы | EFI_PROVIDER |
| Контракт установщика | файл ответов preseed / autoinstall | kickstart | ответы setup-alpine | installerconfig | автоустановка install.conf | нет — только образ | манифест distro constructor | декларативная конфигурация | нет — только образ |
| Подпись | на уровне репозитория | на уровне пакета плюс метаданные репозитория | подпись индекса и префикса пакета | подпись репозитория или отпечаток | подписанный файл хеш-сумм на каждый набор | файлы хеш-сумм | подпись X.509 на каждый пакет | подпись на каждый артефакт | определяется производителем |
Два структурных различия важнее словаря.
Бинарная основа против исходной. В семействах deb, rpm и apk единицей
является заранее собранный пакет, а база составляется разрешением пакетов. В
BSD и семействах на основе исходного кода база — единое дерево, собираемое как
одно целое, а «пакеты» суть способ нарезки результата. Следствия: S4–S5 в
первом случае дёшевы и параллельны, во втором — дороги и неделимы; S9 в первом
случае является задачей разрешения зависимостей, а во втором — простой задачей
промежуточной сборки. Семейства сближаются — pkgbase во FreeBSD превращает
базу в пакеты, IPS и hpkg всегда были пакетными, — но переносимая модель
обязана вмещать оба варианта.
Установщик против образа. Одни семейства поставляют установщик, который управляется файлом ответов. У других нет средств сценирования, и установка выполняется записью подготовленного образа. Адаптер MUST объявить, какую модель он поддерживает; профиль, требующий автоматической установки, не может быть удовлетворён адаптером, работающим только с образами, без дополнительного механизма первого запуска.
4. Досье по семействам
Каждое досье говорит, что семейство даёт производителю даром, чего оно требует и где его острые углы.
4.1 deb
Движки сборки: сборщик live-образов Debian, дающий совмещённый образ живой
системы и установщика; debootstrap, по-прежнему эталонный бутстраппер
установщика и сборочных демонов, и альтернативная реализация mmdebstrap со
слоистой YAML-обёрткой bdebstrap; debos для образов по рецепту внутри
одноразовой виртуальной машины; FAI, который тоже производит и установщик, и
носители живой системы; и mkosi для дисковых, унифицированных ядерных и
OCI-выводов.
Ubuntu собирает форком live-сборщика, управляемым раскрытием seed; её служба
сборки закрыта для третьих сторон.
Сильные стороны: крупнейший архив, служба срезов архива для Debian и Ubuntu, самая сильная программа воспроизводимости среди всех семейств и подписанная цепочка загрузки, которую производная система наследует даром, пока она её не пересобирает.
Острые углы: live-сборщик требует привилегий и не имеет непривилегированного пути; нижестоящие архивы, построенные на старом репозиторном инструментарии, не адресуют индексы по содержимому, поэтому кеширующий прокси перед ними даёт периодические расхождения индексов; файлы пакетов в практике Debian не подписываются, поэтому целостность отдельного файла обеспечивается дайджестами в подписанном индексе, а доверие зависит от свежести индекса.
4.2 rpm
Движки сборки: инструментарий compose Fedora для полных дистрибутивных сборок,
osbuild с декларативными blueprint и манифестом этапов для облачных и
дисковых образов, KIWI для описаний устройств целевого назначения и ISO,
rpm-ostree для систем на основе коммитов с lock-файлом, фиксирующим точные
версии пакетов, и bootc для систем, определяемых как контейнерные образы.
Профильная система mkimage в ALT Linux — самый интересный декларативный
сборщик дистрибутивов в этом семействе; она сочетается с непривилегированной
двухпользовательской песочницей сборки.
Сильные стороны: подписи на уровне пакета, независимые от репозитория; зрелый контракт kickstart для автоматической установки; сильнейшая экосистема формального соответствия с профилями усиления защиты и содержимым для автоматического сканирования, которое сопровождается в рамках того же проекта, что используют программы сертификации.
Острые углы: общей службы посуточных срезов архива нет, поэтому производитель, которому нужна фиксация срезов, вынужден держать собственное неизменяемое зеркало; метаданные репозитория не всегда подписаны по умолчанию даже там, где подписаны пакеты; локальный инструментарий сборки образов исторически умел собирать только то же семейство операционных систем, что и хост сборки, а это вынуждает держать пул сборочных узлов на каждое семейство.
4.3 apk
Движки сборки: скрипты сборки образов Alpine с именованными профилями и архивом оверлея, применяемым при первом запуске; и, за пределами самого Alpine, декларативная пара инструментов, которая собирает пакеты, а затем составляет контейнерные образы вовсе без императивного шага, давая побитово одинаковый вывод и состав продукта для каждой сборки.
Сильные стороны: самые компактные образы, простейший механизм оверлея и семейство, где полностью непривилегированная и побайтово воспроизводимая сборка образа — обычный путь, а не достижение; сопоставимы с этим только декларативные системы на основе исходного кода.
Острые углы: службы срезов архива нет, поэтому фиксация срезов требует зеркала, поддерживаемого производителем; схема подписи не несёт семантики отзыва и срока действия, а на практике доверие к репозиторию обеспечивается единственным файлом ключа; формат пакета находится в середине перехода, поэтому предположения инструментов следует сверять с версией.
4.4 FreeBSD
Сборка: документированная сборка выпуска из дерева исходного кода, управляемая одним файлом конфигурации и дающая установочные носители, образы для карт памяти, образы виртуальных машин и облачные образы; массовый сборщик на основе jail, который производит частный репозиторий пакетов и умеет выпускать образы; минималистичный каркас устройств целевого назначения, доступных только на чтение, с A/B-разделами прошивки; и установщик, управляемый файлом конфигурации, размещённым на носителе.
Сильные стороны: в текущем выпуске базовая система собирается воспроизводимо и без прав root; загрузочные окружения дают полноценный примитив отката; базу теперь можно поставлять пакетами, что заметно приближает семейство к переносимой модели.
Острые углы: подписанного загрузчика, принимаемого основными органами подписи прошивок, нет, поэтому проверенная загрузка требует внесения собственных ключей производителя; классическая утилита обновления базы и база на пакетах взаимно исключают друг друга; путь на основе пакетов не создаёт загрузочное окружение автоматически, поэтому откат производитель организует сам.
4.5 OpenBSD
Сборка: строго упорядоченная сборка сначала ядра, затем пользовательского окружения, дающая фиксированный набор tarball-архивов и установочный образ с memory disk; кастомизация намеренно узка и состоит из site-архива, распаковываемого последним, и установочного скрипта, выполняемого в новом корне; автоматическая установка управляется файлом вопросов и ответов.
Сильные стороны: сильнейшие меры защиты по умолчанию среди всех семейств, очень маленькая база доверия для обновлений, построенная на единственном инструменте подписи с прямой цепочкой ключей, и необычно простой набор артефактов выпуска.
Острые углы: программы воспроизводимых сборок нет; утилита бинарных патчей работает только на неизменённых официальных выпусках, поэтому производная система, пересобирающая базу, её теряет; проект поддерживает только собственные конфигурации ядра, поэтому кастомизированное ядро лишается собственной защитной машинерии проекта.
4.6 NetBSD
Сборка: один сборочный скрипт кросс-собирает полный выпуск — включая устанавливаемые образы — с любого POSIX-хоста, без привилегий, используя журнал метаданных вместо настоящего владения файлами.
Сильные стороны: лучшая во всём семействе Unix история непривилегированной и кросс-платформенной сборки и воспроизводимые сборки, доступные через переключатель сборки.
Острые углы: у установщика нет механизма файла ответов, поэтому автоматическое развёртывание должно идти через образ; средства подписи в системе пакетов существуют, но по умолчанию не включены, поэтому сквозной подписанный канал производителю приходится строить самому.
4.7 Прочие Unix
DragonFly BSD собирает выпуски из отдельного дерева и имеет отличную файловую систему с поддержкой снимков, но не имеет встроенного механизма загрузочных окружений. Дистрибутивы illumos составляются из XML-манифеста, подписывают пакеты цепочкой X.509 и имеют загрузочные окружения, интегрированные с менеджером пакетов, что даёт самую полную историю отката среди не-Linux-систем; при этом система пакетов по замыслу не имеет установочных сценариев, поэтому кастомизация выражается декларативными действиями и актуаторами, а не хуками. Haiku собирается собственным инструментом и монтирует пакеты только на чтение, формируя из них систему. Особый случай — Darwin: открытые части собрать можно, но полезной производной системы не получить, а распространение поставляемой системы запрещено.
4.8 Linux на основе исходного кода и на основе образов
Сборщик выпусков Gentoo фиксирует дерево пакетов по коммиту и собирает через ступенчатые bootstrap-этапы. Nix и Guix описывают всю систему декларативно и фиксируют её lock-файлом или коммитом машины времени, что даёт сильнейшие гарантии фиксации, какие вообще существуют; Guix дополнительно выполняет bootstrap из минимального зерна. Yocto и Buildroot — другой класс: единицей здесь является рецепт, компилируемый из исходного кода кросс-цепочкой, а на целевой системе обычно вовсе нет менеджера пакетов, то есть обновления по построению делаются целым образом. Их кеширование различается резко: у одного есть адресуемый по содержимому кеш на уровне задач, делающий инкрементальные пересборки дешёвыми, у другого его нет.
5. Матрица привилегий
| Возможность | Доступна без привилегий? |
|---|---|
| Создать корневую файловую систему из пакетов | да, в нескольких семействах, через пространства имён пользователя или песочницу сборки |
| Наполнить образ файловой системы из каталога | да, инструментами, которые пишут файловые системы без монтирования |
| Собрать squashfs или ISO | да |
| Смонтировать файловую систему на блочном устройстве, подключить loop-устройство, создать файлы устройств | нет — требует привилегий в начальном пространстве имён |
| Зарегистрировать интерпретатор чужой архитектуры | нет — однократная операция уровня хоста |
| Собрать совмещённый образ живой системы и установщика в семействе deb | нет |
| Кросс-собрать полный выпуск NetBSD | да |
| Собрать выпуск FreeBSD | да, в текущем выпуске |
| Собрать выпуск OpenBSD | фактически нет |
Отсюда два следствия. Во-первых, непривилегированная сборка устраняет целый
класс аварий, но не является границей изоляции; границей является
виртуальная машина (SCF-BLD-002). Во-вторых, адаптер MUST объявлять свои
потребности в привилегиях как возможность, потому что они определяют, какой
класс сборочных узлов может его исполнять.
6. Фиксация срезов архива
| Семейство | Доступная фиксация |
|---|---|
| Debian, Ubuntu | публичные службы срезов архива с доступом по времени |
| Arch | ежедневный публичный архив |
| Gentoo | дерево, зафиксированное по коммиту |
| Nix, Guix | ревизия lock-файла; машина времени, восстанавливающая всю инструментальную цепочку |
| Fedora, RHEL и производные | общей посуточной службы нет; неизменяемые зеркала производителя, замороженные минорные потоки и архивные деревья снятых с поддержки выпусков |
| Alpine | у upstream нет |
| Kali, Mint и подобные нижестоящие | в лучшем случае замороженные ветки срезов |
| BSD | ветки выпусков; порты и пакеты требуют среза, поддерживаемого производителем |
Там, где платформа не даёт такой службы, SCF-SRC-004 обязывает производителя
поддерживать собственный неизменяемый срез архива. Практическая форма —
адресуемое по содержимому зеркало ровно тех входов, которые потребил lock,
хранимое в течение срока поддержки; оно одновременно закрывает обязательства
по доступности исходного кода.
7. Модели подписи
| Модель | Семейства | Следствие |
|---|---|---|
| На уровне репозитория | deb | индекс является корнем доверия; свежесть индекса и адресуемые по содержимому пути индексов важны эксплуатационно |
| На уровне пакета плюс метаданные | rpm | пакет остаётся проверяемым вне своего репозитория; подпись метаданных надо проверять отдельно |
| Префиксный сегмент в архиве | apk | просто и быстро; нет семантики срока действия и отзыва |
| Подписанный манифест хеш-сумм на выпуск | OpenBSD | очень маленькая база доверия; проверка происходит до распаковки |
| Манифест хеш-сумм без подписи по умолчанию | NetBSD | средства подписи существуют, но по умолчанию не включены; подписанный канал обеспечивает производитель |
| Отпечаток репозитория или открытый ключ | FreeBSD | корнем доверия является набор файлов отпечатков, поставляемый с системой |
| Цепочка сертификатов на каждый пакет | illumos | поддерживает уровни политики вплоть до обязательного контроля подписи |
| Подпись артефакта по адресу содержимого | Nix, Guix, OCI | доверие привязано к содержимому, а не к местоположению |
Адаптер MUST раскрывать модель своего семейства как возможность, чтобы
SCF-ART-004 и SCF-UPD-004 можно было проверить, а не принимать на веру.
8. Контракт адаптера
Адаптер допускается, только если он реализует перечисленное ниже и честно объявляет свои возможности.
Операции
| Операция | Требование |
|---|---|
describe | вернуть возможности: выводы, архитектуры, класс привилегий, поддержку фиксации срезов, модель подписи, контракт установщика, класс воспроизводимости |
validate | проверить спецификацию по схеме семейства без побочных эффектов |
resolve | получить lock из спецификации без сборки |
build | выполнить S4–S9 внутри границы, только из lock |
collect | выдать артефакты, манифест, состав продукта и журнал |
Инварианты
Это не новые обязательства. Каждый инвариант повторяет требование Конституции в терминах адаптера и проверяется через него.
| № | Инвариант | Конституция |
|---|---|---|
| 1 | resolve детерминирован для данной спецификации и фиксации среза | SCF-SPC-002, SCF-SRC-004 |
| 2 | build потребляет только lock и не выполняет разрешение заново | SCF-SPC-003, SCF-REP-001 |
| 3 | build не требует сетевого доступа сверх объявленных зеркал | SCF-BLD-004 |
| 4 | build ничего не подписывает | SCF-CRY-003 |
| 5 | каждый артефакт сообщается со своей хеш-суммой и ролью | SCF-ART-001 |
| 6 | отказ — структурированный результат с указанием этапа | SCF-BLD-008 |
| 7 | объявленные возможности проверяются тестами соответствия, а не принимаются на веру | SCF-EVD-001 |
Аттестацию формирует управляющая плоскость из записи сборки, а не среда
сборки (SCF-ART-003, SCF-CRY-003).
9. Выбор подхода
| Требование | Подход |
|---|---|
| Поддержать дистрибутив, конвейер сборки которого закрыт или неотделим от его поставщика | ремастеринг официального образа; это единственный путь для нескольких крупных настольных дистрибутивов, и он сохраняет унаследованную цепочку загрузки |
| Совмещённый носитель живой системы и установщика в семействе deb | сборщик live-образов Debian внутри виртуальной машины |
| Дисковый, корневой, контейнерный или унифицированный ядерный вывод | непривилегированная цепочка «пакеты — файловая система» |
| Максимально сильные фиксация и воспроизводимость | полностью декларативная система на основе исходного кода |
| Устройство целевого назначения с атомарным обновлением и откатом | система на основе образов с A/B- или коммит-развёртыванием |
| Устройство целевого назначения на BSD | собственный инструментарий выпуска семейства плюс репозиторий пакетов, поддерживаемый производителем |
10. Известные невозможности
Их следует фиксировать в профиле продукта, а не обнаруживать поздно.
- Совмещённый образ живой системы и установщика в семействе deb сейчас нельзя произвести без привилегий.
- Производная система, пересобирающая ядро или загрузчик, не может унаследовать подписанную цепочку загрузки upstream.
- Получение подписанного загрузочного компонента у основного органа подписи —
процесс длиной в несколько кварталов, с высокой долей отказов и жёсткими
организационными предпосылками; план продукта MUST NOT зависеть от него
(
SCF-BOOT-005). Измеренные показатели, метод их получения и дата зафиксированы в исследовательском досье по платформам, а не здесь. - Побитовая воспроизводимость достижима не для каждого семейства: у нескольких
нет ни службы архива, ни программы воспроизводимости (
SCF-REP-002). - Внесение ключа платформы производителя в потребительскую прошивку в пользовательском режиме по замыслу требует физического присутствия у машины. Управляемые платформы могут допускать удалённую подготовку или заводское предварительное внесение; профиль продукта MUST указывать, какой случай применим.
- У некоторых семейств нет контракта автоматической установки; такие профили обязаны строиться на образе.