{"id":125748,"date":"2025-06-01T15:05:12","date_gmt":"2025-06-01T13:05:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka"},"modified":"2025-06-01T15:05:12","modified_gmt":"2025-06-01T13:05:12","slug":"inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/novosti-interneta\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","title":{"rendered":"Vorfall mit dem Ersetzen von Commits im Linux-Kernel-Branch von Kesa Cook.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds hat den Administrator von kernel.org aufgefordert, das Konto von Kesa Kuka, dem ehemaligen Hauptsystemadministrator von kernel.org und Leiter des Ubuntu Security Teams, sofort zu sperren. Konstantin Ryabtsev, der f\u00fcr die Infrastruktur von kernel.org verantwortlich ist, hat die Sperrung durchgef\u00fchrt. Der Grund f\u00fcr die Sperrung war ein Pull-Request zur Aufnahme von \u00c4nderungen in den Kernel 6.16 Branch, der sich auf ein Git-Repository bezog, in dem die Autorendaten einiger Commits ge\u00e4ndert wurden. <\/p>\n
Im unterst\u00fctzten Git-Repository von Kess waren gef\u00e4lschte \u00c4nderungen vorhanden, bei denen in den Feldern f\u00fcr Autor und Committer «Linus Torvalds» angegeben war, obwohl Linus sie nicht hinzugef\u00fcgt hatte. Zum Beispiel gab es unter Linus' Namen in Kess' Branch einen Commit, der einen anderen Commit in Linus' Branch wiederholte, jedoch mit einer anderen SHA1-Hash. Beide Commits sehen identisch aus, abgesehen von den Signaturinformationen. <\/p>\n
Die \u00c4nderungen schienen kein zuf\u00e4lliger Fehler beim Ausf\u00fchren des «git rebase» Befehls zu sein, da sie falsche Informationen \u00fcber den Autor des Commits enthielten. Linus Torvalds betrachtete dies als Anzeichen potenziellen sch\u00e4dlichen Verhaltens und initiierte die Sperrung aller \u00c4nderungen von Kess, bis die Gr\u00fcnde f\u00fcr solch manipulatives Verhalten gekl\u00e4rt waren und best\u00e4tigt wurde, dass Kess' System nicht kompromittiert war. <\/p>\n
Kess antwortete, dass er nicht versteht, wie so etwas passieren konnte. Zuvor war er beim Zusammenf\u00fchren mehrerer seiner Git-Branches auf Probleme gesto\u00dfen und versuchte, diese mit «git rebase» zu l\u00f6sen, was jedoch anscheinend nicht half. All dies geschah im Kontext eines Ausfalls der SSD-Festplatte, die w\u00e4hrend des Kopierens Fehler meldete. Kess glaubte, dass er nach dem Ausfall den Zustand seiner Repositories wiederherstellen konnte, aber anscheinend war das nicht der Fall. Um die Integrit\u00e4t wiederherzustellen, beabsichtigt Kess, seine Branches aus einzelnen Patches neu zu erstellen. Als wahrscheinlichste Ursache f\u00fcr die Ver\u00e4nderung des Autors sieht Kess einen misslungenen Versuch, das Repository nach seiner Besch\u00e4digung wiederherzustellen. <\/p>\n
Linus war mit dieser Erkl\u00e4rung nicht zufrieden, da ihm die \u00c4nderungen in der Commit-Historie von Kess sehr absichtlich erschienen und nicht wie ein zuf\u00e4lliger Fehler. Das Rebasieren der \u00c4nderungsverl\u00e4ufe mittels «git rebase» k\u00f6nnte die \u00dcberschreibung des Commiters erkl\u00e4ren, aber Linus kann nicht nachvollziehen, wie eine solche «git rebase» Operation versehentlich durchgef\u00fchrt worden sein k\u00f6nnte. <\/p>\n
Das \u00dcberschreiben eines oder zweier Commits k\u00f6nnte noch als Fehler gelten, aber im Kesa-Repository wurden mehr als sechstausend Merge-Commits \u00fcberschrieben, wobei Linus bei 330 dieser Commits als Autor angegeben wurde, obwohl diese Commits nicht aus Linus' Git-Baum stammen. Die durchgef\u00fchrten \u00c4nderungen erinnern mehr an das Ergebnis eines Skripts als an einen Datenverlust auf dem Speicher, da sie die separate Rekonstruktion jeder Commit-Kopie erfordern. <\/p>\n
Kess versicherte Linus, dass er dies nicht absichtlich getan habe und solche Experimente nicht ohne Vorank\u00fcndigung durchf\u00fchren w\u00fcrde (zum Beispiel war das vergangene Experiment zur Ausl\u00f6sung von Commit-Kollisionen mit Linus abgesprochen). In dieser Woche f\u00fchrte er mehrere manuelle Operationen mit dem Repository durch und wird nun versuchen herauszufinden, was schiefgegangen ist, und das Problem zu reproduzieren. Kess f\u00fchrte beispielsweise eine Rebase-Operation f\u00fcr die Git-B\u00e4ume for-next\/hardening und for-linus\/hardening durch, wobei er im Gegensatz zu fr\u00fcheren \u00e4hnlichen Transformationen den Branch «master» und nicht rc2 verwendete. W\u00e4hrend dieser Operation nahm er \u00c4nderungen an den Skripten zur \u00dcberpr\u00fcfung von Pull-Requests vor. <\/p>\n
Zusatz: Kess Cook ver\u00f6ffentlichte eine weitere Nachricht, in der er erkl\u00e4rte, dass das Problem h\u00f6chstwahrscheinlich durch die Verwendung des Tools «git-filter-repo» entstanden ist, das die Geschichte von Commits im Repository neu schreibt, in Kombination mit dem Befehl «b4 trailers», der dazu dient, Trailer zu Commits zu erhalten und anzuwenden (zum Beispiel «Signed-off-by:»). \n Quelle: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"