Linus Torvalds zażądał od administratora kernel.org natychmiastowego zablokowania konta Kesa Cooka, byłego głównego administratora kernel.org i lidera zespołu bezpieczeństwa Ubuntu, który zarządzał 14 podsystemami związanymi z bezpieczeństwem w jądrze. Konstantin Riabcev, odpowiedzialny za działanie infrastruktury kernel.org, dokonał blokady. Powodem blokady był pull request dotyczący włączenia zmian do gałęzi jądra 6.16, który odnosił się do repozytorium git, w którym zmieniono informacje o autorstwie niektórych commitów.
W obsługiwanym przez Kesa repozytorium git były fikcyjne zmiany, w polu autora i committera wskazującego na "Linus Torvalds", ale Linus ich nie dodał. Na przykład, pod imieniem Linusa w gałęzi Kesa znajdował się commit, który powtarzał inny commit w gałęzi Linusa, ale z innym hashem SHA1. Oba commity wyglądają identycznie, z wyjątkiem informacji o podpisie.
Zmiany nie wyglądały na przypadkowy błąd podczas wykonywania operacji "git rebase", ponieważ zawierały błędne informacje o autorze commita. Linus Torvalds uznał to za ślady potencjalnie złośliwej aktywności i zainicjował blokadę przyjmowania jakichkolwiek zmian od Kesa, do czasu wyjaśnienia przyczyn takich manipulacji oraz potwierdzenia, że system Kesa nie został skompromitowany.
Kes odpowiedział, że nie rozumie, jak mogło do tego dojść. Wcześniej miał problemy z próbą scalania kilku swoich gałęzi git, po czym próbował je rozwiązać operacją "git rebase", ale najwyraźniej to nie pomogło. Całe to zdarzenie miało miejsce na tle awarii dysku SSD, który zgłaszał błędy podczas kopiowania. Kes uważał, że po awarii udało mu się przywrócić stan swoich repozytoriów, ale najwyraźniej tak nie było. W celu przywrócenia integralności Kes zamierza odtworzyć swoje gałęzie z osobnych patchy. Jako najbardziej prawdopodobną przyczynę podmiany autora Kes uważa nieudaną próbę przywrócenia repozytorium po jego uszkodzeniu.
Linus nie był zadowolony z takiego wyjaśnienia, ponieważ jego zdaniem zmiany w historii commitów w repozytorium Kesa są bardzo podobne do działań zamierzonych, a nie do przypadkowej awarii. Zmiana historii commitów za pomocą operacji „git rebase” mogła wyjaśnić nadpisanie commitera, ale Linus nie może zrozumieć, jak taka operacja „git rebase” mogła zostać wykonana przypadkowo.
Nadpisanie jednego lub dwóch commitów można jeszcze przypisać pomyłce, ale w repozytorium Kesa nadpisano ponad sześć tysięcy commitów merge, z których w 330 autorem był Linus, mimo że te commity nie pochodziły z drzewa git Linusa. Wprowadzone zmiany bardziej przypominają działanie skryptu niż wynik uszkodzenia informacji na nośniku, ponieważ wymagają oddzielnego odtworzenia kopii każdego commita.
Kes zapewnił Linusa, że nie zrobił tego celowo i nie przeprowadzałby takich eksperymentów bez ostrzeżenia (na przykład, wcześniejszy eksperyment związany z wywołaniem kolizji commitów został uzgodniony z Linusem). W tym tygodniu wykonywał kilka ręcznych operacji w repozytorium i teraz spróbuje zrozumieć, co poszło nie tak, oraz odtworzyć problem. Na przykład Kes przeprowadzał operację rebase dla drzew git for-next/hardening i for-linus/hardening, używając w odróżnieniu od wcześniejszych podobnych transformacji gałęzi „master”, a nie rc2. W trakcie tej operacji wprowadzał zmiany w skryptach do weryfikacji push-requestów.
Uzupełnienie: Kes Cook opublikował kolejną wiadomość, w której stwierdził, że prawdopodobnie problem wynikł z użycia narzędzia „git-filter-repo”, które wykonuje nadpisanie historii commitów w repozytorium, w połączeniu z komendą „b4 trailers”, przeznaczoną do uzyskiwania i stosowania trailerów do commitów (na przykład „Signed-off-by:”).
Źródło: opennet.ru
