{"id":115167,"date":"2024-04-19T02:30:02","date_gmt":"2024-04-19T00:30:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/v-opensuse-factory-realizovana-podderzhka-povtoryaemyh-sborok"},"modified":"2024-04-19T02:30:02","modified_gmt":"2024-04-19T00:30:02","slug":"v-opensuse-factory-realizovana-podderzhka-povtoryaemyh-sborok","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/news\/v-opensuse-factory-realizovana-podderzhka-povtoryaemyh-sborok","title":{"rendered":"In openSUSE Factory wurde die Unterst\u00fctzung f\u00fcr reproduzierbare Builds implementiert.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Die Entwickler des Projekts openSUSE haben Unterst\u00fctzung f\u00fcr reproduzierbare Builds im Repository openSUSE Factory angek\u00fcndigt, das ein kontinuierliches Versionsaktualisierungsmodell (Rolling-Updates) anwendet und die Basis f\u00fcr die Erstellung der Distribution openSUSE Tumbleweed bildet. Die Build-Konfiguration von openSUSE Factory erm\u00f6glicht es nun, sicherzustellen, dass die in den Paketen verteilten bin\u00e4ren Dateien aus den zur Verf\u00fcgung gestellten Quelltexten erstellt wurden und keine geheimen \u00c4nderungen enthalten. Zum Beispiel kann jeder Benutzer pers\u00f6nlich \u00fcberpr\u00fcfen, dass die angebotenen Builds bitgenau mit den Builds \u00fcbereinstimmen, die pers\u00f6nlich aus den Quelltexten erstellt wurden. <\/p>\n
Bei der Erstellung reproduzierbarer Builds werden Aspekte wie die genaue \u00dcbereinstimmung der Abh\u00e4ngigkeiten, die Verwendung eines unver\u00e4nderten Satzes und der Versionen der Build-Tools, ein identischer Satz von Optionen und Standardeinstellungen sowie die Beibehaltung der Reihenfolge der Dateibauten (Anwendung derselben Sortiermethoden) ber\u00fccksichtigt. Zudem wird das Hinzuf\u00fcgen von nichtbest\u00e4ndiger Hilfsinformation durch den Compiler, wie zuf\u00e4llige Werte, Verweise auf Dateipfade und Daten zu Datum und Uhrzeit des Builds, deaktiviert. <\/p>\n
Die M\u00f6glichkeit, die Identit\u00e4t eines bin\u00e4ren Builds zu \u00fcberpr\u00fcfen, erm\u00f6glicht es, sich nicht nur auf das Vertrauen in die Build-Infrastruktur zu verlassen, da eine Kompromittierung des Compilers oder der Build-Tools zu versteckten Hintert\u00fcren f\u00fchren k\u00f6nnte. Zum Beispiel wurden reproduzierbare Builds von den Entwicklern von openSUSE genutzt, um sch\u00e4dliche Modifikationen auszuschlie\u00dfen, die aufgrund eines Vorfalls mit der Hinzuf\u00fcgung einer Hintert\u00fcr im Paket xz (die kompromittierte Bibliothek liblzma, die zur Entpackung des Archives mit dem GCC-Code verwendet wird, konnte potenziell \u00c4nderungen in den GCC-Code einf\u00fcgen, die zur Einspeisung sch\u00e4dlicher Elemente in die erstellten Anwendungen verwendet werden k\u00f6nnten). <\/p>\n
Das Repository Factory ist nicht f\u00fcr Endbenutzer konzipiert und wird haupts\u00e4chlich von Verteilungsentwicklern genutzt, da keine Stabilit\u00e4t zu jedem Zeitpunkt gew\u00e4hrleistet ist. Die in Factory hinzugef\u00fcgten Systempakete durchlaufen automatisierte Tests mit dem Werkzeug openQA. Nach Abschluss der Tests und der \u00dcberpr\u00fcfung eines konsistenten Zustands wird mehrmals pro Woche der Inhalt des Repositories auf Spiegelserver \u00fcbertragen und ein abgebildeter Zustand ver\u00f6ffentlicht als openSUSE Tumbleweed. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"