Debian muss reproduzierbare Pakete bereitstellen

 (lists.debian.org)
1 Punkte von GN⁺ 5 시간 전 | 2 Kommentare | Auf WhatsApp teilen
  • Das Debian-Release-Team hat beschlossen, mitten im forky-Zyklus reproduzierbare Pakete bereitzustellen
  • Die Migrationssoftware blockiert neue Pakete, die sich auf reproduce.debian.net nicht reproduzieren lassen
  • Auch bei Regressionen der Reproduzierbarkeit in bestehenden Paketen in testing wird die Migration blockiert
  • Für binNMUs wurde ebenfalls die Ausführung von autopkgtest hinzugefügt, wie bei source-full-Uploads
  • Durch die Aufnahme von loong64 und Multi-Arch-Rebuilds ist die CI-Warteschlange größer geworden, weshalb Geduld gefragt ist

Reproduzierbarkeit von Debian-Paketen wird verpflichtend

  • Das Debian-Release-Team hat zur Mitte des forky-Release-Zyklus entschieden, dass Debian reproduzierbare Pakete bereitstellen muss
  • Diese Entscheidung wurde durch die Bemühungen des Reproducible Builds-Projekts ermöglicht
  • Seit gestern ist die Migrationssoftware so aktiviert, dass sie die Migration neuer Pakete blockiert, die sich auf reproduce.debian.net nicht reproduzieren lassen
  • Auch wenn bei bereits in testing vorhandenen Paketen Regressionen der Reproduzierbarkeit auftreten, wird die Migration blockiert

Qualitätssicherung und Verantwortung der Uploader

  • Ausführung von autopkgtest für testing-binNMUs

    • Anfang dieses Jahres wurde der Migrationssoftware die Funktion hinzugefügt, binNMUs ebenso wie source-full-Uploads mit autopkgtest auszuführen
    • Diese Funktion steht möglicherweise nicht in direktem Zusammenhang mit der Arbeit der meisten Maintainer, wird aber als weiterer Schritt zur Stärkung der Qualitätssicherung gesehen

  • Aufnahme der Architektur loong64 und wachsende CI-Warteschlange

    • Vor zwei Wochen wurde die neue Architektur loong64 in das Archiv aufgenommen
    • Debian erlaubt nur die Migration von Binärpaketen, die auf buildd gebaut wurden, und wegen der Multi-Arch-Anforderungen mussten auf allen Architekturen zahlreiche Pakete neu gebaut werden
    • Wegen der zuvor hinzugefügten binNMU-Funktion ist die CI-Warteschlange derzeit recht groß, und das Release-Team bittet um etwas Geduld

  • Nachverfolgung nach dem Upload

    • Uploader von Quellpaketen sind dafür verantwortlich sicherzustellen, dass das betreffende Paket migrieren kann
    • Wenn ein Paket durch eine autopkgtest-Regression einer umgekehrten Testabhängigkeit blockiert wird und dafür ein Update dieser Abhängigkeit nötig ist, muss der Uploader einen Bug mit angemessener RC-Schwere einreichen

Verwandte Beiträge

2 Kommentare

 
GN⁺ 2 시간 전
Hacker-News-Kommentare

  • Das ist ein großer Erfolg für Debian und die Welt der freien Software.
    Allerdings hat es ziemlich lange gedauert, bis die Notwendigkeit verstanden wurde. Als ich 2007 auf debian-devel sagte, dass das nötig sei, bekam ich die Antwort, das sei eine gewaltige Zeitverschwendung. Tatsächlich war enorm viel Arbeit von vielen Leuten nötig, um hierher zu kommen, aber es war es absolut wert.

    • Seit 2007 gab es in Debian keine Bugs oder Angriffe, die durch reproduzierbare Pakete hätten verhindert werden können.
      Deshalb halte ich „es war es wert“ nicht für richtig. Es erhöht nur die Hürden für Beiträge zu Debian, und ich habe schon viele Leute darüber klagen hören, dass Beiträge zu Debian ohnehin schwierig seien. Früher wurde das noch mit „wir brauchen jede Menge Prüfungen und Gegengewichte, damit die Pakete sauber ineinandergreifen“ verteidigt, aber das hier wirkt wie zusätzliche Schwierigkeit ohne echten Grund und mit nur geringem Nutzen.

  • Auf https://wiki.debian.org/ReproducibleBuilds gibt es mehr Informationen. Einiges ist veraltet, aber es gibt dort auch Diagramme, die die Zahl der in CI gebauten Pakete zeigen und wie viele davon reproduzierbare Builds sind.
    Orange steht für FTBR, also „fails to build reproducibly“. Ich bin nicht besonders geübt darin, Zahlen aus solchen Diagrammen abzulesen, aber ich schätze grob ein paar Prozent, etwa 4–5 %.

    • Bei mir kommt nur das hier:

      Forbidden

      You are not allowed to access this!
      Sogar die HTML-Tags werden unverändert angezeigt :)
      Edit: Im Archiv habe ich auch die Seite „I Challenge Thee“ gefunden. Werde ich vielleicht von einer Bot-Schutzmaßnahme blockiert? Warum???

  • Gute Sache. NetBSD hat seit 2017 vollständig reproduzierbare Builds. https://blog.netbsd.org/tnf/entry/netbsd_fully_reproducible_...

    • Wie auch im Link steht, hat NetBSD das mit Hilfe von Debian erreicht. Wenn ich es richtig verstehe, liegt das weniger daran, dass NetBSD härter gearbeitet hätte, sondern eher daran, dass das Problem einfacher war. Es gibt weniger Pakete und weniger Änderungen. Sie benutzen immer noch CVS, also reicht „stabil“ als Beschreibung kaum aus.
      Zur Einordnung: Der Großteil der Debian-Pakete ist bereits reproduzierbar gebaut. Die übrigen, ungefähr 5 %, werden in dem Diagramm hier orange markiert: https://wiki.debian.org/ReproducibleBuilds
    • Um ein wenig anzugeben: stagex hat letztes Jahr als erstes vollständig deterministische und isolierte Builds auf Basis von 100 % Full-Source-Bootstrapping erreicht, und ebenfalls als erstes für jedes Release mehrere signierte Reproduktionen verpflichtend gemacht, die von unterschiedlichen Maintainers auf jeweils eigener Hardware durchgeführt wurden.
      Debian hat große Fortschritte gemacht, aber wenn Debian sagt, es sei reproduzierbar, bedeutet das, dass für den eigenen Build Drittanbieter-Binärdateien herangezogen werden. Wenn wir sagen, es sei reproduzierbar, meinen wir, dass wir die gesamte Software-Lieferkette bis ans Ende zu 100 % aus Source Code bootstrappen.
      Ich halte diesen Unterschied für wichtig.
      https://stagex.tools

  • Ich freue mich wirklich über diese Veränderung. Nachdem ich 2021 über den SolarWinds-Angriff gelesen hatte und schockiert war, habe ich angefangen, mich an reproduzierbaren Builds zu beteiligen. [1]
    Am treffendsten finde ich die Aussage von Magnus Ihse Bursie, der an reproduzierbaren Builds für OpenJDK gearbeitet hat: „Wenn Sie mich fragen, dann war die Tatsache, dass Compiler und Build-Tools irgendwann anfingen, nichtdeterministischen Output zu erzeugen, von Anfang an ein Bug.“ [2]
    [1] https://www.linux.com/news/preventing-supply-chain-attacks-l...
    [2] https://github.com/openjdk/jdk/pull/9152#issue-1270543997

  • Ich frage mich, warum das gerade jetzt ein Thema ist. Ich nutze Yocto für Embedded-Geräte, und reproduzierbare Builds ließen sich dort fast selbstverständlich umsetzen.
    Auch Debian-Paketverwaltung lässt sich leicht aktivieren, daher wirkt es auf mich so, als müsste das doch längst alles möglich sein.

    • Ich frage mich, was genau mit „warum ist das gerade jetzt ein Thema“ gemeint ist.
      Reproduzierbare Builds sind in der industriellen IT eine essenzielle Methode. Debian steht dabei nicht unbedingt an der Spitze dieses Bereichs, sondern übernimmt eher eine branchenweite Praxis, die auch in anderen Betriebssystemen für Langzeitbetrieb und sicherheitsrelevante Einsatzzwecke genutzt wird.
      Natürlich ist vieles davon heute auch deshalb leicht nutzbar, weil Yocto und die Debian-Entwickler bereits viel schwierige Arbeit geleistet haben.
      Interessant ist, dass die Debian-Entwickler das nun als offensivere Richtlinie durchsetzen und es nicht mehr als Option, sondern als Standardnorm etablieren.
    • Mich würde interessieren, ob aktiv überprüft wurde, ob die Builds tatsächlich bitweise reproduzierbar sind.

  • Für amd64 forky:
    reproduced: 97.02%
    good: 17586
    bad: 511
    fail: 30
    unknown: 0
    Diese Statistik sowie Statistiken für andere Architekturen und die Gründe für nicht reproduzierbare Builds finden sich auf https://reproduce.debian.net

  • Ich finde es immer überraschend, dass Debian das vorantreibt und nicht ein kommerzieller Vendor. Man sollte meinen, große Organisationen, die für RHEL und Ubuntu bezahlen, würden stark auf verifizierbare Binärdateien drängen.

    • Wenn ein Konkurrent nachweisen kann, dass sein Paket bitweise identisch mit dem ist, was eine große Organisation ausliefert, dann profitiert dieser Konkurrent von den Sicherheitszusagen dieser großen Organisation.
      Für freie Software ist das großartig, aber für jemanden, der Monopolist sein will, eher nicht.
    • Reproduzierbare Builds existieren, um den Bedarf an Vertrauen zu verringern, kommerzielle Vendoren aber verkaufen Vertrauen.

  • Forbidden
    You don't have permission to access this resource.
    Apache Server at lists.debian.org Port 443
    :/
 
GN⁺ 5 시간 전
Lobste.rs-Kommentare

  • Aus Sicherheitssicht ist das eine gute Veränderung. Der Übergang kann mühsam sein, aber am Ende sorgt er für höheres Vertrauen bei Debian-Linux-Nutzern weltweit.

  • Ich frage mich, was der zentrale Vorteil für ein Projekt wie Debian ist. Geht es darum, dass jeder einen Nachweis dafür hat, dass keine Backdoor in den Binärdateien steckt?
    Also dass dadurch das notwendige Vertrauen in Maintainer sinkt und zugleich das Risiko böswilliger Maintainer reduziert wird? Ich bin nicht skeptisch, ich habe nur nicht zu 100 % verstanden, warum Debian so viel Zeit darauf verwendet. Reproduzierbare Builds zu ermöglichen klingt ziemlich schwierig und arbeitsintensiv.

    • Nicht nur Backdoors, sondern auch gewöhnliche Manipulationen oder Änderungen lassen sich damit nachweisen. Das hilft der Sicherheit und bringt auch Vorteile für die Projektentwicklung, denn Pakete, die reproduzierbar und in einer einigermaßen abgeschotteten Weise gebaut werden, gehen in anderen Entwicklerumgebungen seltener auf seltsame Weise kaputt.
      Im Kern geht es darum, einen Nachweis dafür zu liefern, dass der erzeugte Ausgabepaket tatsächlich aus genau diesem Quellcode entstanden ist und nicht aus einem versteckten zweiten Satz von Quellen. the reproducible-builds org has a bit of a 'why' which puts it better than i can
      Reproduzierbare Builds herzustellen ist sehr schwierig. Schon Zeitstempel in der Compile-Pipeline können Unterschiede verursachen, ebenso die Metadaten erzeugter Archive. All diese Dinge müssen beseitigt werden, und manchmal sind dafür nicht einmal Patches am Paket selbst nötig, sondern an Upstream-Projekten wie CMake oder dem Go-Compiler. In vielen Fällen wurden solche Probleme früher nicht einmal in Betracht gezogen, daher ist Arbeit über den gesamten Build-Stack hinweg nötig. Diese Arbeit läuft allerdings schon lange, und ein großer Teil der zugrunde liegenden Infrastruktur ist bereits erledigt oder weit fortgeschritten.
    • Ich denke nicht, dass das Debians höchste Priorität sein sollte, aber Debian funktioniert nicht so. Die Leute machen das, woran sie arbeiten wollen, und individuelle Prioritäten stimmen oft nicht mit sinnvollen Prioritäten auf Projektebene überein.

  • Ist das, was Debian mit Reproduzierbarkeit meint, dasselbe Konzept wie bei NixOS?

    • Nein. NixOS is not reproducible ist der Standard-Referenzartikel dazu.
    • Distributionen, die reproduzierbare Builds als Projektziel verfolgen, bewegen sich im Großen und Ganzen auf dasselbe Ziel zu. reproducible-builds.org verfolgt die Projekte, die aktiv daran in ihren Paketierungs-Pipelines arbeiten.
      NixOS arbeitet ebenfalls an reproduzierbaren Builds, und wenn ich mich richtig erinnere, ist zumindest das ISO sowohl beim Build als auch zur Laufzeit zu 100 % reproduzierbar. Aber das, was bei NixOS oft als Reproduzierbarkeit bezeichnet wird, ist nicht dasselbe wie die hier diskutierten „reproduzierbaren Builds“. Siehe dazu den foxboron-Artikel, auf den in einem Schwesterkommentar in diesem Thread verwiesen wird. Das ist eher Umgebungs-Reproduzierbarkeit oder „deterministische Builds“ und weiterhin wertvoll, aber nicht das, worum es hier geht.

  • Im Moment klingt das nach einem Ratschenmechanismus. Sind Dinge, die noch nie reproduzierbar gebaut wurden, weiterhin erlaubt?

    • Wenn ein Paket nicht reproduzierbar gebaut werden kann, wird es nicht in die nächste Debian-Version aufgenommen. Das heißt, Pakete, die „noch nie reproduzierbar gebaut wurden“, können zwar in Debian unstable bleiben, aber Pakete dauerhaft in Debian unstable zu behalten, die stable nie erreichen, sieht man nicht gern. Soweit ich weiß, gibt es dafür allerdings keine mechanisch erzwungene Regel.