Преди няколко дни случи се необичаен инцидент, което разтърси общността на ядрото на Linux, и това е Линус Торвалдс нареди незабавното спиране на акаунта на Кийс Кук в kernel.org., след откриване на съществуването на манипулирани комити в Git хранилището на този разработчик.
Кийс Кук, признат за лидерството си в екипа по сигурността на Ubuntu и за поддръжката на повече от дузина подсистеми на ядрото, свързани със сигурността, беше временно забранено да внася промени, докато фактите не бъдат изяснени.
Промяна на авторството и подписите в хранилището на Kees Cook
Проблемът възникна от заявка за включване на промяна.s към клона на ядрото 6.16, в който Линус идентифицира препратки към хранилище които съдържаха манипулирани коммити с името му като автор и потвърдител, въпреки че самият той не ги е правил. Един от най-сериозните примери беше съществуването на дублиран коммит, идентичен по съдържание с оригинала, но с различен SHA1 хеш, който фалшиво включваше подписа на Линус Торвалдс.
Тези промени не може да се отдаде просто на случайна грешкапо време на операция за пребазиране на git, тъй като те включваха мащабна модификация на чувствителна информация, включително над 6.000 пренаписани коммита, 330 от които с името на Линус като автор.
Реакцията на Торвалдс: подозрения за умишлена манипулация
Линус Торвалдс не скри загрижеността си и описа събитията като потенциално злонамерени:
„Едно или две пренаписвания може да са грешка. Но хиляди от тях, много от които с моя фалшифициран подпис, не са“, заяви той.
Предвид мащаба на промените и риска за целостта на официалното дърво на ядрото, Торвалдс попита Константин Рябицев, администратор на инфраструктурата на kernel.org, qда блокира достъпа на Кийс Кук, докато ситуацията не се изясни.
В отговор, Кийс Кук обясни, че наскоро е имал технически проблеми това би могло да е предизвикало инцидента. Той каза, Вашият SSD диск е имал грешки по време на операции по копиране, което е причинило повреда в няколко хранилища. След тези грешки той се опита да възстанови състоянието на хранилището си, използвайки git rebase и различни инструменти за автоматизация.
Тези операции обаче бяха извършени на критични клонове, като например for-next/hardening и for-linus/hardening, което доведе до случайна промяна на историята на хранилището, включително промяната в авторството на коммитовете. Въпреки обяснението му, Линус беше скептичен.:
„Не разбирам как е възможно случайно изпреварване, камо ли с този обем промени.“
Истинският виновник: git-filter-repo и b4 трейлъри
В по-късно съобщение, Кийс Кук идентифицира вероятния източник на грешкатакомбинираното използване на два инструмента, git-filter-repo и b4 трейлъри, които манипулират историята на коммитите и трейлъри (тагове като Signed-off-by:) в коммитовете.
Тази неправилна употреба от печалбите би довело до автоматично пренаписване на хиляди коммити, включително заместване на автора със стойността по подразбиране (в този случай Линус Торвалдс), без Кийс да забележи грешката по това времеКонстантин Рябицев, автор на инструмента b4, потвърди тази теория и заяви, че не е имало злонамерено намерение от страна на Кук. Всъщност системата вече е генерирала предупреждения, които са били игнорирани.
След изясняване на ситуацията, достъпът на Кийс Кук до kernel.org беше възстановен. Като превантивна мярка е обявено, че инструментът b4 ще включва нова проверка за сигурност, Това ще предотврати модифицирането на комити, чието авторство не съвпада с идентичността на текущия потребител отсега нататък. Целта е да се предотвратят подобни грешки и да се защити целостта на изходния код на ядрото.
Кийс, от своя страна, обеща да пресъздаде засегнатите клони. от отделните корекции и да анализираме задълбочено стъпките, довели до грешката. Въпреки че Инцидентът обтегна отношенията в екипа разработката на ядрото, също така подчертава важността на предпазливото използване на инструменти за пренаписване на историята, особено в проекти, толкова критични, колкото ядрото на Linux.
Накрая, заслужава да се спомене, че този инцидент между Линус Торвалдс и Кийс Кук служи като предупреждение за опасностите от манипулирането на историята на комитите и че благодарение на бързата намеса от отговорните за kernel.org и прозрачността на процеса, ситуацията е овладяна.
Накрая, ако се интересувате да научите повече за това, можете да проверите подробностите по-долу връзка.