{"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\/news\/v-debian-utverzhdena-obyazatelnaya-podderzhka-vosproizvodimyh-sborok-paketov","title":{"rendered":"In Debian ist die verpflichtende Unterst\u00fctzung f\u00fcr reproduzierbare Paket-Bauten genehmigt worden.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Das Team, das f\u00fcr die Erstellung von Debian-Versionen verantwortlich ist, hat angek\u00fcndigt, dass die reproduzierbare Neubau von Paketen zu den zwingenden M\u00f6glichkeiten geh\u00f6rt. Gestern wurden \u00c4nderungen im Build-System vorgenommen, die den Transfer neuer Pakete in das Repository blockieren, wenn diese keine Unterst\u00fctzung f\u00fcr reproduzierbare Builds bieten. Auch im Testing-Repository ist das Update bestehender Pakete verboten, wenn diese Regressionen in der Reproduzierbarkeit des Builds aufweisen. <\/p>\n
In Debian 13, das 36427 Quellpakete umfasst, betr\u00e4gt die Unterst\u00fctzung f\u00fcr wiederholbare Builds 96,9% f\u00fcr die Architektur x86_64 und 96,8% f\u00fcr die Architektur ARM64. In den Debian Testing-Repositories wird der Grad an wiederholbaren Builds mit 94,5% f\u00fcr die Architektur ARM64 und 75,7% f\u00fcr x86_64 bei der Neubau von 37809 Quellpaketen bewertet. Der Test f\u00fcr wiederholbare Builds im Debian Testing-Repository wurde f\u00fcr 1141 Pakete (3%) nicht bestanden, und bei 7952 Paketen (21%) traten allgemeine Probleme beim Kompilieren aus dem Quellcode auf. <\/p>\n
Wiederholbare Builds bieten dem Benutzer die M\u00f6glichkeit, eigene Builds zu erstellen, die bitweise mit den angebotenen vorgefertigten Builds \u00fcbereinstimmen. Der Benutzer kann sich pers\u00f6nlich davon \u00fcberzeugen, dass die in den Paketen und Boot-Images verbreiteten Bin\u00e4rdateien aus den bereitgestellten Quelltexten gebaut wurden und keine versteckten \u00c4nderungen enthalten. Die \u00dcberpr\u00fcfung der Identit\u00e4t des Bin\u00e4r-Builds erm\u00f6glicht es, sich nicht nur auf das Vertrauen in die Build-Infrastruktur der Distribution zu verlassen; eine Kompromittierung des Compilers oder des Build-Toolsets kann zu versteckten Hintert\u00fcren f\u00fchren. <\/p>\n
Bei der Erstellung wiederholbarer Builds werden solche Nuancen ber\u00fccksichtigt, wie die exakte \u00dcbereinstimmung der Abh\u00e4ngigkeiten; die Verwendung unver\u00e4nderter Bestandteile und Versionen des Build-Toolsets; identische S\u00e4tze von Optionen und Standardeinstellungen; die Beibehaltung der Reihenfolge des Baus von Dateien (Anwendung derselben Sortiermethoden); die Deaktivierung durch den Compiler hinzugef\u00fcgter nicht konstanter Metainformationen, wie zuf\u00e4llig generierte Werte, Verweise auf Dateipfade und Daten zum Datum und zur Uhrzeit des Builds. Auf die Reproduzierbarkeit der Builds wirken sich auch Fehler und Race Conditions in den Tools aus. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"