Kilka dni temu wydarzył się niezwykły incydent, który wstrząsnął społecznością jądra Linuksa, i to jest Linus Torvalds nakazał natychmiastowe zawieszenie konta Keesa Cooka na kernel.org., po wykryciu istnienia zmanipulowanych zatwierdzeń w repozytorium Git tego programisty.
Kees Cook, doceniony za swoje przywództwo w zespole ds. bezpieczeństwa Ubuntu i za utrzymanie ponad tuzina podsystemów jądra związanych z bezpieczeństwem, został tymczasowo pozbawiony możliwości przesyłania zmian do czasu wyjaśnienia faktów.
Zmiana autorstwa i podpisów w repozytorium Keesa Cooka
Problem pojawił się w wyniku wniosku o zmianę.s do gałęzi jądra 6.16, w którym Linus zidentyfikował odniesienia do repozytorium który zawierał zatwierdza manipulowane za pomocą jego nazwisko jako autora i potwierdzającego, mimo że sam tego nie uczynił. Jednym z najpoważniejszych przykładów było istnienie zduplikowanego zatwierdzenia, o identycznej zawartości jak oryginał, ale z innym skrótem SHA1, które fałszywie zawierało podpis Linusa Torvaldsa.
Te zmiany nie można tego przypisać wyłącznie przypadkowemu błędowil podczas operacji git rebase, ponieważ wiązały się z masową modyfikacją poufnych informacji, w tym ponad 6.000 przepisanych zmian, z czego 330 miało nazwisko Linusa jako autora.
Reakcja Torvaldsa: podejrzenia celowej manipulacji
Linus Torvalds nie krył swojego zaniepokojenia i opisał te wydarzenia jako potencjalnie złośliwe:
„Jedna lub dwie poprawki mogą być błędem. Ale tysiące z nich, wiele z moim sfałszowanym podpisem, nie są” – oświadczył.
Biorąc pod uwagę skalę zmian i ryzyko dla integralności oficjalnego drzewa jądra, Torvalds zapytał Konstantina Riabitseva, administrator infrastruktury kernel.org, qzablokować dostęp Keesa Cooka do czasu wyjaśnienia sytuacji.
W odpowiedzi Kees Cook wyjaśnił, że ostatnio miał problemy techniczne co mogło wywołać incydent. Powiedział, Na dysku SSD wystąpiły błędy podczas operacji kopiowania, które spowodowały uszkodzenie w kilku repozytoriach. Po tych błędach próbował odzyskać stan swojego repozytorium za pomocą git rebase i różnych narzędzi automatyzacyjnych.
Jednakże operacje te były wykonywane na gałęziach krytycznych, takie jak for-next/hardening i for-linus/hardening, co doprowadziło do przypadkowej modyfikacji historii repozytorium, w tym zmiany autorstwa zatwierdzeń. Mimo wyjaśnień Linus był sceptyczny.:
„Nie rozumiem, jak mogło dojść do przypadkowego wyprzedzania, a co dopiero przy takiej liczbie zmian”.
Prawdziwy winowajca: git-filter-repo i zwiastuny b4
W późniejszej wiadomości, Kees Cook zidentyfikował prawdopodobne źródło błędu:połączone użycie dwóch narzędzi, git-filter-repo i zwiastuny b4, które manipulują historią zatwierdzania i zwiastuny (tagi takie jak Signed-off-by:) w zatwierdzeniach.
To nieprawidłowe użycie zysków spowodowałoby automatyczne przepisanie tysięcy zatwierdzeń, w tym zastąpienie autora wartością domyślną (w tym przypadku Linus Torvalds), bez zauważenia przez Keesa błędu w chwili jego wystąpieniaKonstantin Ryabitsev, autor narzędzia b4, potwierdził tę teorię i stwierdził, że Cook nie miał złych intencji. W rzeczywistości system już generował ostrzeżenia, które były ignorowane.
Po wyjaśnieniu sytuacji Kees Cook uzyskał przywrócony dostęp do kernel.org. W ramach środków zapobiegawczych ogłoszono, że narzędzie b4 będzie zawierać nową kontrolę bezpieczeństwa, Zapobiegnie to modyfikacji zatwierdzeń, których autorstwo nie pasuje do tożsamości bieżącego użytkownika od teraz. Ma to na celu zapobieganie podobnym błędom i ochronę integralności kodu źródłowego jądra.
Kees ze swojej strony zobowiązał się do odtworzenia uszkodzonych gałęzi. z poszczególnych poprawek i dogłębnie przeanalizować kroki, które doprowadziły do błędu. Chociaż Incydent ten nadwyrężył stosunki w zespole Rozwój jądra Linuxa podkreślił również znaczenie ostrożnego korzystania z narzędzi do przepisywania historii, zwłaszcza w przypadku tak ważnych projektów jak jądro Linuxa.
Na koniec warto wspomnieć, że incydent między Linusem Torvaldsem a Keesem Cookiem stanowi ostrzeżenie przed niebezpieczeństwami związanymi z manipulowaniem historią zatwierdzania i że dzięki szybkiej interwencji od osób odpowiedzialnych za kernel.org i przejrzystość procesu, sytuacja została opanowana.
Na koniec, jeśli jesteś zainteresowany, aby dowiedzieć się więcej, możesz sprawdzić szczegóły poniżej link