LINUX.ORG.RU
ФорумTalks

Насколько бинарные сборки соответствуют лицензиям


0

1

Упёрто с опеннета

Для Ъ:

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

В качестве эксперимента было произведено сравнение исполняемых файлов, поставляемых в составе дистрибутивов Debian, Fedora и openSUSE, с исполняемым файлом, собранным из доступных пакетов с исходными текстами. Для теста выбран пакет с утилитой tar. В теории, зная все параметры сборки и версии используемых при сборке компонентов, можно воссоздать исходное сборочное окружение, сборка пакета с исходными текстами в котором должна привести к получению тождественных исполняемых файлов. На практике всё оказалось не так просто, при каждой сборке получались разные исполняемые файлы. Основной причиной различий является сохранение в исполняемом файле данных, связанных со временем сборки.

При оценке пересборки пакетов Debian результаты полностью оправдали предположения - различие составило 20 байт, и в этих байтах содержалась дата сборки. Для openSUSE и Fedora не удалось достигнуть повторяемости или хотя бы объяснить причину значительных различий. В качестве наиболее вероятной гипотезы отмечаются возможные отличия в сформированной для тестирования сборочной среде - для сборки использовалась текущая версия тестируемого дистрибутива, но не факт, что аналогичное окружение были использовано разработчиками, а даже при незначительных изменениях используемого инструментария результат меняется кардинально.

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

Думаю стоит дистрам стандартизиовать окружение для сборки. У меня на jessie tar собрался со 100500 различиями.

Дискасс.

★★

Для openSUSE и Fedora не удалось достигнуть повторяемости или хотя бы объяснить причину значительных различий

У них есть проприетарные патчи, добавляющие бэкдоры.

CYB3R ★★★★★
()

у меня на работе была как-то раз такая проблема. Нужно было пересобрать бинарник, который был бы до байта идентичен тому, что уже был собран ранее. Долго я с ней провозился, в итоге пришел к выводу, что 100% идентичными их сделать невозможно. Но поскольку отладочные символы и всякая прочая лабуда, не участвующая в логике и выполнении программы существенной роли не играет, стал сравнивать только секции кода. Исход - при неизменном окружении сборки (компилятор, либы - все хранится свое), повторяемые бинарники реальны.

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

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

GateKeeper ★★
()

Без приведения точной спецификации сборочной среды невозможно проверить на основе представленных исходных текстов собрано приложение или в нём использованы какие-либо модификации.

В Makefile привидения водятся а они про какие-то идентичные бинарники и спецификации говорят.

Napilnik ★★★★★
()

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

И это правильно, ибо зп CM'ов (Configuration Manager) упадет раза в 3-5 :)

gh0stwizard ★★★★★
()

Расскажите поцону о strip и отладочной информацие.

IPR ★★★★★
()

А потому что надо всё собирать в chroot с минимальным окружением.

rezedent12 ☆☆☆
()

такие думатели не нужны. Боишься блекдоров - используй сборку из исходников, или source-based дистрибутив. А новомодных стандартизаторов, нужно выкинуть на помойку.

qnikst ★★★★★
()

он наркоман, процесс сборки суси полностью прозрачен, скорее всего он собирал с исползованием апдейтов, тогда как бинарь тара собирался еще до апдейтов, плюс в не в родных инстурментах дистра.
https://build.opensuse.org/package/live_build_log?arch=i586&package=tar&a... вот лог
скачал tar-1.26-14.1.1.x86_64.rpm (6f45f498102b28cfe757776456a04bec) и распаковал
md5sum /tmp/tarr/bin/tar
35651e25c9bb21376065c3206cee8508 /tmp/tarr/bin/tar

теперь

osc co openSUSE:12.3 tar
cd ./openSUSE\:12.3/tar/
osc build -j3

/var/tmp/build-root/standard-x86_64/.build.packages/RPMS/x86_64/tar-1.26-0.x86_64.rpm (99dec18a85b8a515eca3c2c6d93834a2) распаковываем

md5sum /tmp/tar/bin/tar
35651e25c9bb21376065c3206cee8508 /tmp/tar/bin/tar


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

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

щас они попросят тебя дифф tar-1.26-0.x86_64.rpms и канонiчного тара.

// Gentoo rulez!

dib2 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.