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» такого ограничения нет.

P.S. То, что в исключительных случаях выкладывают в обход этой системы, называется «binary-only non-maintainer upload», и их осуждают в постах выше.

question4 ★★★★★
()
Последнее исправление: question4 (всего исправлений: 2)
Ответ на: комментарий от 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 ★★★★★
()
Ответ на: комментарий от question4

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

Нет. Это загрузка новой версии пакета исходников немантейнером (самостоятельно или с помощью спонсора).

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

Нет. Это пересборка пакета без изменения пакета исходников в дебиановском сборочном окружении.

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

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

Нет. Это загрузка новой версии пакета исходников немантейнером (самостоятельно или с помощью спонсора).

Зачем эта процедура нужна, помимо критических исправлений?

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

Нет. Это пересборка пакета без изменения пакета исходников в дебиановском сборочном окружении.

Зачем эта процедура нужна, помимо проблем со сборочной системой?

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

ну, вот пример, навскидку. кто-нибудь из фанатов дебьяна сможет найти хотя бы описание того, чем именно отличаются версии 0.4.9+nmu2 и 0.4.9+nmu1 от 0.4.9, не говоря уж об исходниках?

я сам на дебьяне 20 лет сижу (хотя фанатом не являюсь) и нарывался на такое неоднократно.

зы. ну, ладно, описание изменений типа есть в чейнжлоге. но каким образом это сделано - узнать невозможно, поскольку в Сальсе это не отражается. и как вот это они собираются «воспроизводимо собирать»?

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

чем именно отличаются версии 0.4.9+nmu2 и 0.4.9+nmu1 от 0.4.9,

Описание есть в changelog.

не говоря уж об исходниках

https://sources.debian.org/src/ethstatus/

каким образом это сделано - узнать невозможно, поскольку в Сальсе это не отражается

https://salsa.debian.org/debian/ethstatus/-/compare/debian%2F0.4.9..debian%2F0.4.9+nmu2?from_project_id=107059

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

Зачем эта процедура нужна, помимо критических исправлений?

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

Зачем эта процедура нужна, помимо проблем со сборочной системой?

Например:

libperlio-utf8-strict-perl (0.010-1+b3) sid; urgency=low, binary-only=yes
  * Binary-only non-maintainer upload for riscv64; no source changes.
  * Rebuild against perl 5.40

liborcus (0.19.2-6+b1) sid; urgency=low, binary-only=yes
  * Binary-only non-maintainer upload for riscv64; no source changes.
  * Rebuild with Python 3.13 as default
undef ★★★
()

А пользователи Gentoo смотрят на все эти «новшества» со снисходительной улыбкой :)

Kroz ★★★★★
()

Может какой-нибудь иностранный товарищ майор пытался надавить на разработчиков, и они таким образом это обошли, сделав добавление закладок в бинарники практически нереализуемым - это легко будет замечено?

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

А пользователи Gentoo смотрят на все эти «новшества» со снисходительной улыбкой :)

Оба два?

err
()

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

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

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

«Послушайте! Ведь, если звезды зажигают — значит — это кому-нибудь нужно? Значит — это необходимо, чтобы каждый вечер над крышами загоралась хоть одна звезда?!» — В. Маяковский, «Послушайте!».

Сделали - значит, нужно. Кому именно и для чего - другой вопрос... Хотя бы для того, чтобы понять и убедиться, что это не нужно... возможно, иначе этого было не понять... :)

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