LINUX.ORG.RU

В Debian утверждена обязательная поддержка воспроизводимых сборок пакетов

 


0

1

Команда, отвечающая за формирование релизов Debian, объявила о переводе воспроизводимой пересборки пакетов в число обязательных возможностей. Вчера в сборочную систему внесены изменения, блокирующие перенос в репозиторий новых пакетов, не поддерживающих воспроизводимую сборку. В репозитории testing также запрещено обновление существующих пакетов, в которых выявлены регрессии с воспроизводимостью сборки.

В Debian 13, насчитывающем 36427 исходных пакетов, поддержка повторяемых сборок составляет 96.9% для архитектуры x86_64 и 96.8% для архитектуры ARM64. В репозиториях Debian Testing уровень повторяемых сборок оценён в 94.5% для архитектуры ARM64 и 75.7% для x86_64 при пересборке 37809 исходных пакетов. Тест повторяемых сборок в репозитории Debian Testing провален для 1141 пакета (3%), а у 7952 пакетов (21%) возникли общие проблемы при компиляции из исходного кода.

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

При формировании воспроизводимых сборок учитываются такие нюансы, как точное соответствие зависимостей; использование неизменного состава и версий сборочного инструментария; идентичный набор опций и настроек по умолчанию; сохранение порядка сборки файлов (применение тех же методов сортировки); отключение добавления компилятором непостоянной служебной информации, такой как случайные значения, ссылки на файловые пути и данные о дате и времени сборки. На воспроизводимость сборок также влияют ошибки и состояния гонки в инструментарии.

>>> Источник

★★

Проверено: hobbit ()
Последнее исправление: hobbit (всего исправлений: 2)

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

ога. особенно nmu-бинарники, исходников которых в открытом доступе просто не бывает, и что именно там «пофиксили», знает только тот, кто их загрузил (и это даже не мейнтейнер).

очередная профанация от дебьяновской бюрократии.

alegz ★★★★★
()
Последнее исправление: alegz (всего исправлений: 2)

Какого рода «повторяемости» они добиваются? Что один и тот же компилятор даст одинаковый бинарник на разных машинах? Или чего-то большего?

question4 ★★★★★
()
Ответ на: комментарий от question4

один и тот же компилятор даст одинаковый бинарник на разных машинах? Или чего-то большего?

Да. Точнее, что в src.deb сборочная среда будет описана настолько подробно, что собирая из него бинарный deb всегда получаешь то же самое.

Кароч, guix из гiвна и палок.

Camel ★★★★★
()

Рассказали бы хоть, что такое эти ваши воспроизводимые сборки, и почему меня это как-то касается.

Dispetcher14 ★★★★★
()
Ответ на: комментарий от alegz

ога. особенно nmu-бинарники, исходников которых в открытом доступе просто не бывает, и что именно там «пофиксили», знает только тот, кто их загрузил (и это даже не мейнтейнер).

Вот зачем писать о том, в чём вы ничерта не разбираетесь? NMU загружаются в виде пакетов с исходным кодом. binNMU собираются из них же.

Rootlexx ★★★★★
()
Ответ на: комментарий от Dispetcher14

типа пользователь, усомнившись в компиляторах дебъян-серверов, может скачать исходники сборочной машины провести тестовую компиляцию и увидеть что при тех же входных условиях его локальная сборочная машина собрала вот ровно такой же бинарь, который всовывается в пакет дебъяна.
т.е. в любой момент можно независимо проверить работу сборочных машин каждого пакета дебъяна…
а то вдрук там незаметно накладываются патчики от ЦРУ/КГБ/МИ-6/МОССАД(по вкусу)…

мне помнится что мейнтейнеры некоторые пакеты собирают у себя и потом загружают пакет в репу. обшибаюсь ??

pfg ★★★★★
()
Последнее исправление: pfg (всего исправлений: 1)
Ответ на: комментарий от pfg

мне помнится что мейнтейнеры некоторые пакеты собирают у себя и потом загружают пакет в репу. обшибаюсь ??

Точно знаю, что ряд пакетов из Дебиана выкинули из-за того, что не смогли наладить автоматическую сборку. Возможно, для каких-нибудь «non-free» такого ограничения нет.

question4 ★★★★★
()
Ответ на: комментарий от question4

nmu-бинарники

Что это?

https://wiki.debian.org/NonMaintainerUpload
https://wiki.debian.org/binNMU

A non-maintainer upload (NMU) is an upload of a package to the Debian archive by a developer who is not the maintainer of the package. This should usually not be the case, but in special cases (such as for RC bugs, when the maintainer does not respond to the bug report) it is allowed.

То есть спешный фикс, когда основной сопровождающий не отзывается.

A binNMU is a binary-only non-maintainer upload. This is necessary when the build for a specific architecture failed, or produced buggy packages, due to a problem in the build environment itself (not due to an error in the package source). Such problems include library transitions or a misconfiguration on the package maintainer’s machine

То есть готовый бинарник, который выложили из-за проблем со сборочной машиной или регрессиями при обновлении библиотек.

question4 ★★★★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.