Какова цель использования Guix в Gitian? Разве это не приводит к зависимостям и проблемам безопасности?

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

С другой стороны, Guix предназначен для запуска непосредственно на самом хосте, поэтому, если выполняются какие-либо неаудированные и ненадежные сторонние двоичные файлы, они могут нанести ущерб хосту.

Поэтому некоторые разработчики, особенно luke-jr, хотят выполнять сборки Guix на виртуальной машине, чтобы свести к минимуму этот риск. Этого можно было бы добиться, установив Guix внутри виртуальной машины, но у нас уже есть Gitian и инфраструктура вокруг него, поэтому этого также можно добиться, запустив Guix внутри Gitian и избавив таких разработчиков от необходимости выяснять, как установить Guix в виртуальной машине и поддерживать виртуальную машину.

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

Конечно, рекомендуемый метод по-прежнему заключается в использовании Guix напрямую, а не через Gitian. Существует значительное снижение производительности при использовании Guix внутри Gitian. Кроме того, прямой запуск Guix позволяет легче отлаживать и решать проблемы, поскольку набор инструментов и дополнительные созданные двоичные файлы по-прежнему будут доступны для сборщика.

fanquake ответил на это в IRC:

Существует ряд преимуществ использования Guix в качестве среды сборки релиза (или просто системы сборки в целом).

Используя Gitian, вы должны выбрать дистрибутив Linux для сборки. Это определяет ваши наборы инструментов, доступные пакеты, glibc, против которого работает ваша сборка, и т. д.

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

Например, наши тесты проверки безопасности полагаются на ряд опций -no-*, присутствующих в mingw-w64 ld. Эти параметры были пропатчены в ld в пакете Ubuntu Bionic binutils-mingw-w64, однако сопровождающий binutils решил прекратить делать это в Ubuntu Focal, что означало, что наши тесты проверки безопасности не могли быть запущены (с тех пор они решил перепропатчить их в Хирсуте). См. # 18629 для более подробной информации.

В Guix, поскольку мы полностью контролируем наши цепочки инструментов, нам не нужно беспокоиться о подобных проблемах, и мы можем просто напрямую применять нужные патчи, и это именно то, что мы сделали в #22381. , где мы начали исправлять параметры компоновщика -no-* в нашу цепочку инструментов mingw-w64. Параметры компилятора/компоновщика или значения по умолчанию, на которые мы можем положиться, больше не могут случайно меняться из-под нас.

На это кто-то может сказать: «Ну, просто не меняйте базовый образ Ubuntu, и ничего не изменится». На это я бы сказал, что я не хочу, чтобы проект оказался в положении, когда мы «застряли» и не могли обновить наш базовый образ, чтобы использовать новые инструменты (например, компиляторы), потому что, делая это, мы Я просто сломаю что-нибудь еще, например, наши тесты безопасности.

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

«Ну, почему бы просто не исправить / изменить что-то в gitian» - я не буду много говорить об этом, за исключением того, что среда gitian совсем не настроена для того, чтобы делать такие же исправления, которые мы можем довольно тривиально достичь в Guix. Попытка пропатчить и скомпилировать, например, тулчейн mingw-w64 в дескрипторе gitian тоже просто обернется ужасным беспорядком.

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

Это имеет последствия для обратной совместимости, поскольку версия glibc, с которой вы строите, по существу определяет вашу совместимость с glibc во время выполнения. Однако это можно расширить, используя своего рода «обходные пути», которые у нас есть в настоящее время в нашем коде glibc-back-compat.

Теперь, как и в ситуации, когда вы можете захотеть использовать более новую версию Ubuntu (по ряду причин), это будет означать, что вам придется выполнять сборку с использованием более новой версии glibc (вы просто получаете любую версию, поставляемую с этой версией Ubuntu). .

Это означает, что по мере того, как вы используете более новые версии glibc, количество «обходных путей», необходимых для поддержания обратной совместимости, накапливается, постоянно усложняется и даже начинает просачиваться из кода Bitcoin Core в нашу систему зависимостей. Посмотрите все PR, связанные с этим комментарием: https://github.com/bitcoin/bitcoin/pull/22418#issuecomment-876379846 .

Изменения, подобные этой утечке в зависимости, плохи, потому что теперь сборщики нормалей, использующие зависимости, теперь подвержены побочным эффектам патчей, которые действительно необходимы только в нашей среде сборки релиза. Может быть, вы возразите, что в этом случае мы должны применять патчи зависимостей только при сборке релизов, однако тогда у вас есть ситуация, когда релизные сборки еще больше отличаются от «обычных» сборок/сборок для разработчиков, и это означает либо поддержку даже более сложные процедуры CI / тестирования, или они просто оказываются менее протестированными (угадайте, какой из них произойдет с большей вероятностью).

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

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

Это то, что мы сделали недавно, в #22365. Сейчас мы используем glibc 2.27 для RISC-V HOST и используем glibc 2.24 для всех остальных, сохраняя при этом совместимость во время выполнения с glibc 2.17. Вы заметите, что это достигается без необходимости использования каких-либо обходных путей из нашего кода glibc-back-compat (#22405) или любых других PR/изменений, упомянутых в комментарии выше.

Это всего лишь два очень практических преимущества, которые дает использование Guix (их больше), которые в конечном итоге все сводятся к тому, что мы гораздо лучше контролируем нашу среду сборки релиза. Чему я очень рад, и я думаю, что это имеет смысл для такого проекта, как Bitcoin Core.

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

Guix также является гораздо более вероятным путем к полностью самозагружаемым сборкам Bitcoin Core, который когда-либо мог предоставить gitian.

Донгкарл заявил:

Я не думаю, что мы собираемся запускать Guix внутри Gitian для релизов, но лично я думаю, что люди вольны делать все, что сочтут целесообразным, если они намерены его поддерживать.

Люк-младший добавил:

Вы не потеряете эти преимущества Guix, запустив его внутри gitian; gitian просто обеспечивает изоляцию, необходимую для предотвращения регресса безопасности.