Was ist der Zweck der Verwendung von Guix innerhalb von Gitian? Führt das nicht wieder zu Abhängigkeiten und Sicherheitsbedenken?

Gitian erreichte die Reproduzierbarkeit durch die Verwendung einer virtuellen Maschine, um die zum Erstellen verwendete Toolchain zu isolieren. Dies bedeutet, dass alle ungeprüften und nicht vertrauenswürdigen Binärdateien von Drittanbietern in einer geschlossenen Umgebung ausgeführt werden, in der sie das Hostsystem weniger wahrscheinlich verschmutzen und beschädigen.

Andererseits soll Guix direkt auf dem Host selbst ausgeführt werden, so dass ungeprüfte und nicht vertrauenswürdige Binärdateien von Drittanbietern, die ausgeführt werden, dem Host Schaden zufügen könnten.

Daher möchten einige Entwickler, insbesondere luke-jr, Guix-Builds in einer virtuellen Maschine ausführen, um dieses Risiko zu minimieren. Dies könnte durch die Installation von Guix innerhalb einer virtuellen Maschine erreicht werden, aber wir haben bereits Gitian und die Infrastruktur darum herum, also ist es auch möglich, dies zu erreichen, indem Guix innerhalb von Gitian ausgeführt wird und solche Entwickler nicht herausfinden müssen, wie man es installiert Guix in einer VM und warte die VM.

Darüber hinaus haben viele Leute, die am reproduzierbaren Build-Prozess teilgenommen haben, möglicherweise noch kein Guix-Setup. Indem Guix innerhalb von Gitian ausgeführt wird, können diese Leute mit minimalen Änderungen am neuen Veröffentlichungsprozess teilnehmen. Die Bereitstellung eines einfachen Übergangs von Gitian zu Guix ist die Hauptmotivation für die Aktivierung von Guix in Gitian.

Natürlich ist die empfohlene Methode immer noch, Guix direkt statt über Gitian zu verwenden. Es gibt eine erhebliche Leistungseinbuße bei der Verwendung von Guix innerhalb von Gitian. Darüber hinaus ermöglicht die direkte Ausführung von Guix, Probleme einfacher zu debuggen und zu bearbeiten, da die Toolchain und die erstellten zusätzlichen Binärdateien weiterhin für den Builder verfügbar sind.

fanquake hat dies im IRC beantwortet:

Es gibt eine Reihe von Vorteilen, die mit der Verwendung von Guix als Release-Build-Umgebung (oder einfach als Build-System im Allgemeinen) einhergehen.

Wenn Sie Gitian verwenden, müssen Sie eine Linux-Distribution auswählen, auf der Sie aufbauen können. Dies definiert Ihre Toolchains, verfügbare Pakete, die Glibc, gegen die Sie bauen, usw.

Dies bedeutet auch, dass Sie den Entscheidungen der Upstream-Paketbetreuer unterliegen. Sie steuern, wie/wann Paketversionen aktualisiert werden, welche Patches auf sie angewendet werden, wie sie kompiliert werden usw. Dies hat Nachteile.

Beispielsweise verlassen sich unsere Sicherheitsprüfungstests auf eine Reihe von -no-*-Optionen, die in mingw-w64 ld vorhanden sind. Diese Optionen wurden im Paket binutils-mingw-w64 von Ubuntu Bionic in den ld gepatcht, der Betreuer von binutils entschied sich jedoch dafür, dies in Ubuntu Focal einzustellen, was bedeutete, dass unsere Sicherheitsprüfungstests nicht hätten ausgeführt werden können (sie haben es seitdem beschlossen, sie in Hirsute neu zu patchen). Siehe #18629 für weitere Details.

Da wir in Guix die volle Kontrolle über unsere Toolchains haben, müssen wir uns über solche Probleme keine Gedanken machen und können die Patches, die wir verwenden möchten, einfach direkt anwenden, und genau das haben wir in #22381 getan , wo wir damit begonnen haben, die Linker-Optionen -no-* in unsere mingw-w64-Toolchain zu patchen. Compiler-/Linker-Optionen oder Standardeinstellungen, auf die wir uns verlassen können, können sich nicht mehr zufällig unter uns ändern.

Dazu könnten einige sagen: "Nun, ändern Sie einfach nicht das Ubuntu-Basisimage, und die Dinge werden sich nicht ändern". Dazu würde ich sagen, ich möchte nicht, dass das Projekt in einer Position ist, in der wir "stecken bleiben" und unser Basis-Image nicht aktualisieren können, um neue Tools (z. B. Compiler) zu verwenden, weil wir dadurch Ich werde nur etwas anderes kaputt machen, wie unsere Sicherheitstests.

Es scheint klüger, das Potenzial für diese Art von Problemen einfach vollständig zu beseitigen, indem wir genau die gewünschte Release-Build-Umgebung erstellen und verwenden.

"Nun, warum nicht einfach Dinge in Gitian patchen / ändern" - Ich werde dazu nicht viel sagen, außer dass die Gitian-Umgebung überhaupt nicht dafür eingerichtet ist, die gleiche Art von Patchen durchzuführen, die wir ziemlich trivial in Guix erreichen können. Der Versuch, beispielsweise die mingw-w64-Toolchain in einem Gitian-Deskriptor zu patchen und zu kompilieren, würde ebenfalls nur zu einem schrecklichen Durcheinander werden.

Dasselbe gilt für den Versuch, mit Gitian irgendetwas mit einer anderen Glibc zu erstellen, als die, die bereits in dieser Version von Ubuntu verfügbar ist.

Dies hat Auswirkungen auf die Abwärtskompatibilität, da die Version von glibc, gegen die Sie bauen, im Wesentlichen Ihre Glibc-Kompatibilität zur Laufzeit bestimmt. Dies kann jedoch erweitert werden, indem die Art von "Workarounds" verwendet wird, die wir derzeit in unserem glibc-back-compat-Code haben.

Nun, ähnlich wie in der Situation, in der Sie vielleicht eine neuere Ubuntu-Version verwenden möchten (aus einer Reihe von Gründen), bedeutet dies, dass Sie gegen eine neuere glibc bauen müssen (Sie erhalten einfach die Version, die mit dieser Version von Ubuntu geliefert wird). .

Das bedeutet, dass, wenn Sie neuere Versionen von glibc verwenden, die Anzahl der „Problemumgehungen“, die Sie benötigen, um die Abwärtskompatibilität aufrechtzuerhalten, sich häufen, immer komplizierter werden und sogar beginnen, aus dem Bitcoin Core-Code und in unser Abhängigkeitssystem auszulaufen. Sehen Sie sich alle PRs an, die in diesem Kommentar verlinkt sind: https://github.com/bitcoin/bitcoin/pull/22418#issuecomment-876379846 .

Solche Änderungen, die in Abhängigkeiten einsickern, sind schlecht, weil jetzt normale Builder, die Abhängigkeiten verwenden, jetzt den Nebenwirkungen von Patches ausgesetzt sind, die nur in unserer Release-Build-Umgebung wirklich notwendig sind. Vielleicht würden Sie argumentieren, dass wir in diesem Fall beim Erstellen von Releases nur die abhängigen Patches anwenden sollten, aber dann haben Sie eine Situation, in der Release-Builds noch stärker von „normalen“/Entwickler-Builds abweichen, und dies bedeutet, dass Sie entweder einen Ausgleich beibehalten komplexere CI-/Testroutinen, oder sie werden einfach weniger getestet (raten Sie mal, welche davon wahrscheinlicher ist).

Wenn das alles nur nach einem komplizierten Durcheinander klingt, liegt es im Grunde daran, dass es so ist. Die Lösung mit Guix ist jedoch eigentlich ziemlich einfach.

Wenn wir die vollständige Kontrolle über unsere Release-Umgebung haben, können wir genau die Version von glibc auswählen, die wir verwenden möchten (sogar auf einer Ebene pro Host), was wir definitiv nicht auf irgendeine Art und Weise erreichen könnten, wenn überhaupt, mit gitian.

Das haben wir kürzlich in #22365 gemacht. Wir bauen jetzt mit glibc 2.27 für den RISC-V-HOST und mit glibc 2.24 für alle anderen, während wir die Laufzeitkompatibilität mit glibc 2.17 beibehalten. Sie werden feststellen, dass dies erreicht wird, ohne dass Sie eine der Problemumgehungen aus unserem glibc-back-compat-Code (#22405) oder einer der anderen im obigen Kommentar erwähnten PRs / Änderungen verwenden müssen.

Dies sind nur zwei sehr praktische Vorteile, die die Verwendung von Guix bietet (es gibt noch mehr), die letztendlich alle darauf hinauslaufen, dass wir eine viel größere Kontrolle über unsere Release-Build-Umgebung haben. Etwas, worüber ich mich sehr freue und das meiner Meinung nach für ein Projekt wie Bitcoin Core sehr sinnvoll ist.

Die Tatsache, dass es auch viele Leute im Guix-Raum gibt, die aktiv an der Bootstrap-Fähigkeit arbeiten, ist nur ein weiterer großer Bonus, und selbst wenn das nicht genau so funktioniert, wie es manche vielleicht gerade jetzt wollen, wird es Monat für Monat schnell verbessert.

Guix ist auch ein viel wahrscheinlicherer Weg zu vollständig Bootstrap-fähigen Bitcoin Core-Builds als das, was Gitian jemals bieten könnte.

dongcarl sagte:

Ich glaube nicht, dass wir Guix innerhalb von Gitian für die Veröffentlichungen ausführen werden, aber ich persönlich denke, dass es den Leuten freisteht, alles zu tun, was sie für sinnvoll halten, wenn sie sich dazu verpflichten, es zu pflegen

luke-jr fügte hinzu:

Sie verlieren diese Vorteile von Guix nicht, wenn Sie es innerhalb von Gitian ausführen; gitian bietet lediglich die nötige Isolierung, um einen Rückfall in die Sicherheit zu vermeiden