{"id":170570,"date":"2026-05-10T18:25:01","date_gmt":"2026-05-10T16:25:01","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-debian-utverzhdena-obyazatelnaya-podderzhka-vosproizvodimyh-sborok-paketov"},"modified":"2026-05-10T18:25:01","modified_gmt":"2026-05-10T16:25:01","slug":"v-debian-utverzhdena-obyazatelnaya-podderzhka-vosproizvodimyh-sborok-paketov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/v-debian-utverzhdena-obyazatelnaya-podderzhka-vosproizvodimyh-sborok-paketov","title":{"rendered":"In Debian wurde die verpflichtende Unterst\u00fctzung f\u00fcr reproduzierbare Paketbuilds genehmigt.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Team, das f\u00fcr die Erstellung von Debian-Releases verantwortlich ist, hat angek\u00fcndigt, dass die M\u00f6glichkeit zur reproduzierbaren Neubau von Paketen eine Pflichtfunktion wird. Gestern wurden \u00c4nderungen an der Build-System vorgenommen, die den Transfer neuer Pakete ins Repository blockieren, wenn diese keine reproduzierbare Erstellung unterst\u00fctzen. Im Testing-Repository ist zudem das Update bestehender Pakete untersagt, bei denen Regressionsprobleme in Bezug auf die reproduzierbare Erstellung festgestellt wurden. <\/p>\n
In Debian 13, das 36.427 Quellpakete umfasst, liegt die Unterst\u00fctzung f\u00fcr reproduzierbare Builds bei 96,9 % f\u00fcr die Architektur x86_64 und 96,8 % f\u00fcr die Architektur ARM64. Im Debian Testing-Repository wird der Anteil der reproduzierbaren Builds mit 94,5 % f\u00fcr ARM64 und 75,7 % f\u00fcr x86_64 bei der Neubau von 37.809 Quellpaketen bewertet. Der Test f\u00fcr reproduzierbare Builds im Debian Testing-Repository ist f\u00fcr 1.141 Pakete (3 %) fehlgeschlagen, und bei 7.952 Paketen (21 %) gab es allgemeine Komplikationen beim Kompilieren aus dem Quellcode. <\/p>\n
Wiederholbare Builds erm\u00f6glichen es dem Nutzer, eigene Builds zu erstellen, die bitgenau mit den zum Download angebotenen vorgefertigten Builds \u00fcbereinstimmen. Der Nutzer kann pers\u00f6nlich \u00fcberpr\u00fcfen, dass die in Paketen und Abbildungen enthaltenen Bin\u00e4rdateien aus den bereitgestellten Quelltexten erstellt wurden und keine versteckten \u00c4nderungen enthalten. Die \u00dcberpr\u00fcfung der Identit\u00e4t der Bin\u00e4rbuilds erm\u00f6glicht es, sich nicht nur auf das Vertrauen in die Build-Infrastruktur des Distributions zu verlassen; eine Kompromittierung des Compilers oder der Build-Tools k\u00f6nnte zur Einschleusung versteckter Hintert\u00fcren f\u00fchren. <\/p>\n
Bei der Erstellung reproduzierbarer Builds m\u00fcssen Aspekte wie die genaue \u00dcbereinstimmung der Abh\u00e4ngigkeiten, die Verwendung unver\u00e4nderlicher Komponenten und Versionen des Build-Tools, ein identisches Set an Standardoptionen und -einstellungen sowie die Beibehaltung der Sortierreihenfolge der Dateien (Verwendung derselben Sortiermethoden) ber\u00fccksichtigt werden. Au\u00dferdem sollte das Hinzuf\u00fcgen von nicht konstanten Metainformationen durch den Compiler, wie zuf\u00e4llige Werte, Verweise auf Dateipfade und Daten zu Datum und Uhrzeit des Builds, verhindert werden. Auch Fehler und Race Conditions im Build-Tool k\u00f6nnen die Reproduzierbarkeit von Builds beeinflussen. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"