В RedoxFS и сборке появились воспроизводимые сборки: детерминированные архивы и хеши BLAKE3

В сборочной системе Redox включены детерминированные архивы в binutils, а в sysroot добавлены хеши BLAKE3. Одинаковый исходный код теперь даёт побайтово одинаковые библиотеки.

Что такое воспроизводимая сборка

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

В результате две сборки отличаются, хотя код одинаковый. Дальше это мешает: нельзя сравнить два бинарных файла и сказать, что они идентичны, а проверка безопасности должна доверять содержимому, а не подписи.

Что сделано

В binutils включены детерминированные архивы: библиотеки теперь собираются без изменчивых данных внутри. В sysroot добавлены хеши BLAKE3 для каждой собранной библиотеки — по ним можно определить, изменилась ли зависимость, и обновлять только её, а не пересобирать всё подряд.

Отдельной работой объединены рецепты базовой системы и initfs.

Зачем это нужно разработчику

Практическая польза — воспроизводимость. Тот же коммит Redox даёт ту же систему, а значит, поведение и ошибки можно воспроизвести точно. Это особенно важно, когда ОС собирают с нуля.

Хеши в sysroot решают другую задачу: обновление одной зависимости не должно требовать пересборки всех, кто на неё смотрит. При большом числе рецептов это разница между получасовой и многочасовой пересборкой.

Оригинал

Коммит Enable deterministic *.a files on binutils от 17 апреля 2026 года в репозитории redox-os/redox; сводка «This Month in Redox — April 2026», разделы «Build System Improvements» и «System Improvements»