Vorfall mit dem Ersetzen von Commits im Linux-Kernel-Branch von Kesa Cook.

Linus Torvalds forderte den Administrator von kernel.org auf, das Benutzerkonto von Kesa Kuka, dem ehemaligen Hauptsystemadministrator von kernel.org und Leiter des Ubuntu Security Teams, das 14 mit Sicherheit verbundenen Subsysteme im Kernel betreut, sofort zu sperren. Konstantin Ryabtsev, verantwortlich für die Infrastruktur von kernel.org, führte die Sperrung durch. Grund für die Sperrung war ein Pull-Request zur Aufnahme von Änderungen in den Kernel-Branch 6.16, der sich auf ein Git-Repository bezog, in dem die Autorinformationen einiger Commits geändert wurden.

Im von Kesa unterstützten Git-Repository gab es gefälschte Änderungen, bei denen im Autor- und Committer-Feld "Linus Torvalds" angegeben wurde, aber Linus sie nicht hinzugefügt hatte. Zum Beispiel gab es unter Linus' Namen in Kesa's Branch einen Commit, der einen anderen Commit in Linus' Branch wiederholte, jedoch mit einem anderen SHA1-Hash. Beide Commits sehen identisch aus, abgesehen von den Signaturinformationen.

Die Änderungen schienen kein zufälliger Fehler während der Ausführung des "git rebase"-Befehls zu sein, da sie falsche Informationen über den Autor des Commits enthielten. Linus Torvalds hielt dies für Anzeichen potenziell böswilliger Aktivitäten und initiierte die Sperrung der Annahme jeglicher Änderungen von Kesa, bis die Ursachen solcher Manipulationen geklärt und bestätigt wird, dass Kesa's System nicht kompromittiert wurde.

Kesa antwortete, dass er nicht verstehe, wie das passieren konnte. Davor hatte er Probleme beim Versuch, mehrere seiner Git-Branches zu mergen, und versuchte dann, diese mit dem Befehl "git rebase" zu lösen, aber anscheinend half das nicht. All dies geschah vor dem Hintergrund eines Ausfalls des SSD-Speichers, der beim Kopieren Fehler erzeugte. Kesa war der Meinung, dass es ihm nach dem Ausfall gelang, den Zustand seiner Repositories wiederherzustellen, aber das scheint nicht der Fall zu sein. Um die Integrität wiederherzustellen, beabsichtigt Kesa, seine Branches aus einzelnen Patches neu zu erstellen. Als wahrscheinlichste Ursache für die gefälschten Autoreninformationen sieht Kesa einen misslungenen Versuch, das Repository nach dessen Beschädigung wiederherzustellen.

Linus war mit dieser Erklärung nicht zufrieden, da seiner Meinung nach die Änderungen in der Commit-Historie im Kesa-Repository sehr absichtlich erscheinen und nicht wie ein zufälliger Fehler wirken. Das Rebasieren der Versionshistorie mit dem Befehl „git rebase“ könnte das Umschreiben des Committers erklären, aber Linus kann nicht nachvollziehen, wie ein solcher Befehl „git rebase“ aus Versehen ausgeführt worden sein könnte.

Das Umschreiben eines oder zweier Commits könnte man vielleicht noch als Fehler werten, aber im Repository von Kesa wurden mehr als sechstausend Merge-Commits umgeschrieben, von denen 330 von Linus verfasst wurden, obwohl diese Commits nicht aus Linus' git-Baum stammen. Die vorgenommenen Änderungen erinnern eher an die Arbeit eines Skripts als an das Ergebnis eines Datenverlusts auf einem Speichergerät, da sie eine separate Rekonstruktion jeder Commit-Kopie erfordern.

Kes versicherte Linus, dass er dies nicht absichtlich getan hatte und solche Experimente nicht ohne Vorwarnung durchführen würde (zum Beispiel war das letzte Experiment zu Commit-Kollisionen mit Linus abgesprochen). In dieser Woche führte er mehrere manuelle Operationen im Repository durch und wird nun versuchen herauszufinden, was schiefgelaufen ist und das Problem zu reproduzieren. Beispielsweise führte Kes einen Rebase-Befehl für die git-Bäume for-next/hardening und for-linus/hardening aus, wobei er im Gegensatz zu vorherigen ähnlichen Änderungen den Branch „master“ und nicht rc2 verwendete. Während dieser Operation nahm er Änderungen an den Skripten zur Überprüfung von Pull-Requests vor.

Zusatz: Kes Cook veröffentlichte eine weitere Mitteilung, in der er erklärte, dass das Problem wahrscheinlich durch die Verwendung des Dienstprogramms „git-filter-repo“ verursacht wurde, das die Commit-Historie im Repository umschreibt, in Kombination mit dem Befehl „b4 trailers“, der dazu dient, Trailer zu Commits zu erhalten und anzuwenden (zum Beispiel „Signed-off-by:“).

Quelle: opennet.ru