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ür die Infrastruktur von kernel.org verantwortlich ist, hat die Sperrung durchgeführt. Der Grund für die Sperrung war ein Pull-Request zur Aufnahme von Änderungen in den Kernel 6.16 Branch, der sich auf ein Git-Repository bezog, in dem die Autorendaten einiger Commits geändert wurden.
Im von Kesa unterstützten Git-Repository gab es gefälschte Änderungen, bei denen im Feld für den Autor und Committer „Linus Torvalds“ angegeben war, obwohl Linus diese nicht hinzugefügt hat. Zum Beispiel gab es unter Linus' Namen einen Commit im Branch von Kesa, der einen anderen Commit im Branch von Linus wiederholte, jedoch mit einem anderen SHA1-Hash. Beide Commits sehen gleich aus, abgesehen von den Signaturinformationen.
Die Änderungen schienen kein zufälliger Fehler beim Ausführen des Befehls „git rebase“ zu sein, da sie falsche Informationen über den Autor des Commits enthielten. Linus Torvalds betrachtete dies als Hinweise auf möglicherweise schädliche Aktivitäten und initiierte die Blockierung des Empfangs jeglicher Änderungen von Kees, bis die Gründe für solche Manipulationen geklärt und bestätigt werden konnten, dass Kees' System nicht kompromittiert war.
Kees antwortete, dass er nicht verstehe, wie so etwas passieren konnte. Zuvor war er auf Probleme gestoßen, als er versuchte, mehrere seiner Git-Branches zusammenzuführen, woraufhin er versuchte, diese mit dem Befehl „git rebase“ zu lösen, was jedoch offenbar nicht half. All dies geschah vor dem Hintergrund eines Ausfalls der SSD, der beim Kopieren Fehler erzeugte. Kees dachte, dass es ihm nach dem Ausfall gelungen sei, den Zustand seiner Repositories wiederherzustellen, doch offenbar war dem nicht so. Um die Integrität wiederherzustellen, hat Kees vor, seine Branches aus einzelnen Patches neu zu erstellen. Als die wahrscheinlichste Ursache für die entstandene Autoränderung hält Kees einen misslungenen Versuch, das Repository nach seiner Beschädigung wiederherzustellen.
Linus war mit dieser Erklärung nicht zufrieden, da er der Meinung ist, dass die Änderungen der Commit-Historie im Kesas Repository sehr nach absichtlichem Handeln und nicht nach einem zufälligen Fehler aussehen. Das Rebasieren der Änderungsverlauf mit dem Befehl „git rebase“ könnte das Überschreiben des Committers erklären, aber Linus kann nicht nachvollziehen, wie eine solche Operation „git rebase“ versehentlich durchgeführt worden sein könnte.
Das Überschreiben eines oder zweier Commits könnte noch als Fehler gelten, aber im Kesa-Repository wurden mehr als sechstausend Merge-Commits überschrieben, wobei Linus bei 330 dieser Commits als Autor angegeben wurde, obwohl diese Commits nicht aus Linus' Git-Baum stammen. Die durchgeführten Änderungen erinnern mehr an das Ergebnis eines Skripts als an einen Datenverlust auf dem Speicher, da sie die separate Rekonstruktion jeder Commit-Kopie erfordern.
Kees versicherte Linus, dass er das nicht absichtlich gemacht hat und solche Experimente nicht ohne Vorwarnung durchführen würde (zum Beispiel wurde das letzte Experiment, das Kollisionen von Commits hervorrief, mit Linus abgestimmt). 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. Zum Beispiel führte Kees einen Rebase-Vorgang für die Git-Bäume for-next/hardening und for-linus/hardening durch, indem er im Gegensatz zu früheren ähnlichen Umwandlungen den Branch „master“ und nicht rc2 verwendete. Im Zuge dieser Operation nahm er Änderungen an den Skripten zur Überprüfung von Pull-Anfragen vor.
Zusatz: Kees Cook veröffentlichte eine weitere Mitteilung, in der er erklärte, dass das Problem höchstwahrscheinlich durch die Verwendung des Dienstprogramms „git-filter-repo“ entstanden ist, das die Commit-Historie im Repository umschreibt, in Kombination mit dem Befehl „b4 trailers“, der dazu dient, Trailer an Commits zu erhalten und anzuwenden (zum Beispiel „Signed-off-by:“).
Quelle: opennet.ru
