Доступен (https://www.opennet.ru/tips/3100_gnu_guix_heritage.shtml) перевод статьи (https://www.gnu.org/software/guix/blog/2019/connecting-repro.../) Людвика Курте, в которой рассказано как в дистрибутиве GNU Guix связать повторяемые сборки, позволяющие убедиться в тождественности бинарных файлов эталонным исходным текстам, с загрузкой исходных текстов из архива кода Software Heritage (https://www.softwareheritage.org/). Software Heritage ставит перед собой задачу создания полного архива всех доступных в Сети исходных текстов. Код загружается из разных источников (GitHub, репозитории Debian, коллекции GNU и т.п.) с автоматичкеским переносом информации об изменениях, формируя таким образом историю развития кода разных проектов (можно посмотреть каким код был в разное время).
В Guix можно использовать Software Heritage для получения кода, если репозиторий из которого собран пакет, перестал существовать. В контексте повторяемых сборок пользователь может загрузить из Software Heritage состояние кода проекта, соответствующее имеющемуся бинарному пакету, и проверить что бинарные файлы собраны именно из этого кода без добавления скрытых изменений.
URL: https://www.opennet.ru/tips/3100_gnu_guix_heritage.shtml
Новость: https://www.opennet.ru/opennews/art.shtml?num=50425
> В Guix можно использовать Software Heritage для получения кода, если репозиторий из которого собран пакет, перестал существовать
> и проверить что бинарные файлы собраны именно из этого кода без добавления скрытых измененийОднако, полезная вещь.
Чем это лучше hasher от ALT Linux?
Очевидно тем, что это не ALT Linux
Тем, что hasher недостаточно для задачи, которую тут решают?Тут привязка к зависимостям не на уровне версий пакетов, а конкретной ревизии (коммита) сорцов для каждого проекта. И проверка идентичности сборки, если не совпал хэш с требуемым - значит что-то пошло не так. Добиваются совпадения бит-в-бит.
В альтернативах типа mock или hasher привязка на уровне обычных зависимостей, где может обновится сборка при той же формальной (с точки зрения пакета) версии, но из-за изменений сборка с новой версией не будет идентична бит-в-бит. Ну и результирующую контрольную сумму никто с эталоном не сверяет, там просто никто не ведет никаких эталонов.
Хотя вот тут какое-то совпадение хешей показали https://www.altlinux.org/%D0%92%D0%BE�...
Но в плане качества это ничем не лучше того же remock (https://github.com/kholia/ReproducibleBuilds)И на этот хэш никто потом не завязывается (в смысле требования получать тот же хэш при последующих сборках)
Ну а как там все-таки разруливается, что компиляция программулины компилятором gcc 8.1 приведет к такой-то бинари, а компилятором gcc 8.2 - вот к такой? И с каких это пор одна лишь ревизия gcc достаточна? - он сам по себе может быть собран с патчами или без, с такими-то опциями или сякими-то. Не бывает четкой связи между "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское количество предпосылок и допущений.
> без, с такими-то опциями или сякими-то. Не бывает четкой связи между
> "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское
> количество предпосылок и допущений.Судя по документу, у них как раз мегарепа с копией исходников всех проектов. Т.е. git clone (ну или иное, если изначально не гит) для всего вообще, что используется. И ссылка на коммит в этой их копии это однозначно конкретные исходники.
И когда они такое делают для абсолютно всех зависимостей, получается идентичность.
Разумеется, версию gcc также менять нельзя...
> Ну а как там все-таки разруливается, что компиляция программулины компилятором gcc 8.1
> приведет к такой-то бинари, а компилятором gcc 8.2 - вот к
> такой? И с каких это пор одна лишь ревизия gcc достаточна?
> - он сам по себе может быть собран с патчами или
> без, с такими-то опциями или сякими-то. Не бывает четкой связи между
> "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское
> количество предпосылок и допущений.вы не понимаете суть
у вас есть версия в которой написано что собрана она таким-то компилятором с такой то ревизии из проекта Heritage
вы можете проверить это экспериментальным путёма если авторы пакета не способны предоставить указание о версии компилятора и номере ревизии из проекта Heritage (или аналога), то вы им говорите что они скриптокидихацкеры, и бинарный пакет у них брать не будете
> Ну а как там все-таки разруливается, что компиляция программулины компилятором gcc 8.1
> приведет к такой-то бинари, а компилятором gcc 8.2 - вот к
> такой? И с каких это пор одна лишь ревизия gcc достаточна?
> - он сам по себе может быть собран с патчами или
> без, с такими-то опциями или сякими-то. Не бывает четкой связи между
> "ревизией (коммитом) сорцов" и бинарем. А чтобы она случилась, нужно сверхгигантское
> количество предпосылок и допущений.Очевидно, что результат сборки пакетов есть результат некоторой функции сборки от друх переменный: исходников и сборочного окружения. И результаты для одних и тех же исходников, но разных сборочных окружений, может различаться. Поэтому для воспроизведения сборки необходимо хранить информацию о сборочном окружении для кадого собранного пакета. Не знаю, что сделано в Heritage, в ALT для информация о них хранится в сборочных тасках и заносится в индекс собранных пакетов.
ALT Linux не запрещен на территории Российской Федерации! А этот ваш, который на Х - может с самими террористами связан.
Каждый фрагмент кода рекламируемой Вами сборки имеет отечественный копирайт? Причем числящийся не за частным лицом или частной компанией, а за государственным учреждением? Очевидно, нет. В таком случае данный дистрибутив не имеет ровно никаких отличий от любого иного дистрибутива. Его упоминание в каких-то там реестрах не означает ничего, кроме фактов упоминания в реестрах.
Дык в том-то и соль, что ALT - в "каких-то там реестрах" не упоминается. Это вы все норовите софтом, пропагандирующим всякое гейство, пользоваться.Хорошо, что хоть Роскомнадзор стоит на страже - иначе как у ALT пользовательская база-то появится?
Вот поэтому nixos и guixsd нужно что-то вроде ipfs
> ALT Linux не запрещен на территории Российской Федерации!это временно
> Чем это лучше hasher от ALT Linux?Hasher решает другую задачу: изолированной сборки пакетов, которая исключает влияние хост-системы на сборочное окружение и наоборот. Software Heritage же — это репозиторий исходных кодов, из которых были собраны пакеты, и информации о бинарных сборок этих пакетов. В ALT этому ближе gears-репозитории и индексы исходных пакетов.
> Чем это лучше hasher от ALT Linux?Вообще-то тут правильнее сравнивать с Gears.
Hasher -- это более низкоуровневый инструмент, аналог дебиановского pbuilder-а, ну или рхеловского mock.
Что касается сравнения с Gears, то правильный ответ -- ничем. Эти инструменты заточены под оси с принципиально разными архитектурными подходами. Да, они выполняют в них схожий функционал, но они не могут заменить друг друга от слова совсем.
>полного архива всех доступных в Сети исходных текстовМогущественное сосредоточение датацентров правительства ощущаю я.
Круто.
GUIX хорошая идея, но на убунту накатить не осилил за пару часов, собственно на этом решил и забть.
На openSUSE сделал следующее:$ zypper in guix
$ sudo systemctl enable --now guix-daemon.serviceДальше выполнил пункты 7-8 здесь (substitute server authorisation и application setup): http://guix.info/manual/en/Binary-Installation.html#Binary-I...
И всё работает.
Если в вашем дистре пока нет guix, то следуйте инструкциям начиная с первого пункта или соберите "родной" для вашего дистра пакет (deb/rpm/etc.). Я в своё время сделал ebuild для Gentoo, когда его ещё не было ни в одном оверлее или в основной репе Gentoo, и это было крайне просто.
FYI, поделюсь опытом своей ошибки в начале. guix refresh будет пытаться сам определить наличие более свежих версий пакетов в апстриме с разных источников. С опцией --update он будет заменять файлы с определениями пакетов на диске. Не пытайтесь вызвать эту команду без аргументов и без надобности, скорее всего она провалился из-за rate limit'ов на github и других серверах. Если же в качестве аргументов команды указать список пакетов для рефреша, то наличие новых версий будет проверено лишь для них, и это вполне безопасно. Если вы не собираетесь самостоятельно обновлять пакеты до версий, определений которых ещё нет в git-репе guix, и бинарных пакетов для которых ещё нет на substitute-серверах, то команда guix refresh вам не нужна. Вместо этого обновляйте определения из git-репы через guix pull и бинарные пакеты через guix package -u. Кроме того, guix pull обновляет и сам пакетный менеджер guix вместе со всеми его модулями, но при этом не затрагивает то, что было установлено через хостовой пакетный менеджер. Фактически у каждого пользователя guix на одной машине может быть его отдельная копия, или даже несколько разных копий.
P.S. Если будет жалеться на отсутствие /usr/lib/libgit2 или /usr/lib64/libgit2, то установите libgit2-devel или libgit2-dev в вашем хостовом дистре.
Небольшая поправка: пункт 7 в моём случае выглядел так:$ guix archive --authorize < /usr/share/guix/ci.guix.info.pub
> Людвика Курте, в которойОн [людовИк кортЭз].
Желающие приглашаются посмотреть-послушать его в ты-трубе.