{"id":106631,"date":"2023-02-03T18:48:10","date_gmt":"2023-02-03T16:48:10","guid":{"rendered":"https:\/\/prohoster.info\/?p=106631"},"modified":"2023-02-03T21:50:32","modified_gmt":"2023-02-03T19:50:32","slug":"sboi-v-sistemah-sborki-iz-za-izmeneniya-kontrolnyh-summ-arhivov-v-github","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/sboi-v-sistemah-sborki-iz-za-izmeneniya-kontrolnyh-summ-arhivov-v-github","title":{"rendered":"Ausf\u00e4lle in den Build-Systemen aufgrund ge\u00e4nderter Pr\u00fcfziffern der Archive in GitHub.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
GitHub hat die Methode zur Erstellung von automatisch generierten Archiven «.tar.gz» und «.tgz» auf den Release-Seiten ge\u00e4ndert, was zu Ver\u00e4nderungen ihrer Pr\u00fcfziffern und massiven Ausf\u00e4llen in automatisierten Build-Systemen f\u00fchrte. Diese Systeme \u00fcberpr\u00fcfen die Integrit\u00e4t, indem sie die von GitHub heruntergeladenen Archive mit zuvor gespeicherten Pr\u00fcfziffern abgleichen, die beispielsweise in den Metadaten von Paketen oder in Build-Skripten zu finden sind. <\/p>\n
Mit dem Release 2.38 wurde im Git-Toolkit standardm\u00e4\u00dfig eine integrierte gzip-Implementierung hinzugef\u00fcgt, die eine einheitliche Unterst\u00fctzung dieser Komprimierungsmethode in verschiedenen Betriebssystemen erm\u00f6glicht und die Leistung bei der Erstellung von Archiven verbessert. GitHub hat die \u00c4nderung \u00fcbernommen, nachdem die Git-Version in seiner Infrastruktur aktualisiert wurde. Das Problem entstand, weil die von der integrierten gzip-Implementierung auf Basis von zlib erzeugten komprimierten Archive bin\u00e4r von den Archiven abweichen, die mit dem gzip-Tool erstellt wurden, was zu unterschiedlichen Pr\u00fcfziffern f\u00fcr Archive f\u00fchrte, die mit verschiedenen Git-Versionen beim Ausf\u00fchren des Befehls «git archive» erstellt wurden. <\/p>\n
Nach dem Update von Git auf GitHub wurden auf den Release-Seiten etwas andere Archive bereitgestellt, die nicht mit den alten Pr\u00fcfziffern \u00fcbereinstimmten. Dieses Problem trat in verschiedenen Build-Systemen, kontinuierlichen Integrationssystemen und in Paket-Build-Tools auf. Zum Beispiel scheiterte der Build von etwa 5800 FreeBSD-Paketen, deren Quelltexte von GitHub heruntergeladen wurden. <\/p>\n
Als Reaktion auf die ersten Beschwerden \u00fcber die aufgetretenen Fehler wiesen die Vertreter von GitHub zun\u00e4chst darauf hin, dass f\u00fcr Archive keine permanenten Pr\u00fcfziffern garantiert werden. Nachdem jedoch aufgezeigt wurde, dass zur Wiederherstellung der Funktionsf\u00e4higkeit der betroffenen Build-Systeme erhebliche Anstrengungen erforderlich sind, um die Metadaten in verschiedenen \u00d6kosystemen zu aktualisieren, \u00e4nderten die Vertreter von GitHub ihre Meinung, hoben die \u00c4nderung auf und stellten das alte Verfahren zur Archivgenerierung wieder her. <\/p>\n
Die Git-Entwickler haben bisher noch keine Entscheidung getroffen und diskutieren lediglich m\u00f6gliche Ma\u00dfnahmen. Dabei werden Optionen in Betracht gezogen, wie das Zur\u00fccksetzen auf die Standardnutzung des gzip-Tools, das Hinzuf\u00fcgen des Flags \u201e\u2014stable\u201c zur Wahrung der Kompatibilit\u00e4t mit \u00e4lteren Archiven, die Bindung der integrierten Implementierung an ein separates Archivformat sowie die Verwendung des gzip-Tools f\u00fcr \u00e4ltere Commits und der integrierten Implementierung f\u00fcr Commits ab einem bestimmten Datum. Au\u00dferdem wird besprochen, die Stabilit\u00e4t des Formats nur f\u00fcr unkomprimierte Archive zu garantieren. <\/p>\n
Die Schwierigkeit bei der Entscheidungsfindung erkl\u00e4rt sich dadurch, dass das Zur\u00fccksetzen auf den Aufruf eines externen Tools das Problem der Unver\u00e4nderlichkeit der Pr\u00fcfziffern nicht vollst\u00e4ndig l\u00f6st, da \u00c4nderungen im externen gzip-Programm ebenfalls zu \u00c4nderungen im Archivformat f\u00fchren k\u00f6nnen. Derzeit liegt ein Satz an Patch-Vorschl\u00e4gen zur \u00dcberpr\u00fcfung vor, der das alte Verhalten (Aufruf des externen gzip-Tools) standardm\u00e4\u00dfig wiederherstellt und die integrierte Implementierung verwendet, wenn das gzip-Tool nicht im System vorhanden ist. Die Patches f\u00fcgen zudem in der Dokumentation den Hinweis hinzu, dass die Stabilit\u00e4t der Ausgabe von \u201egit archive\u201c nicht garantiert ist und das Format in Zukunft ge\u00e4ndert werden kann. \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"