Несколько дней назад произошел необычный инцидент, который потряс сообщество разработчиков ядра Linux, и это Линус Торвальдс распорядился немедленно заблокировать аккаунт Киза Кука на kernel.org., после обнаружения наличия измененных коммитов в репозитории Git этого разработчика.
Кис Кук, признан за его лидерство в команде безопасности Ubuntu и за поддержку более дюжины подсистем ядра, связанных с безопасностью, временно запрещено вносить изменения до выяснения фактов.
Изменение авторства и подписей в репозитории Киса Кука
Проблема возникла из-за запроса на внесение изменений.s к ветке ядра 6.16, в котором Линус указал ссылки на репозиторий это содержало коммиты манипулируются с его имя как автора и подтверждающего, хотя он сам этого не делал. Одним из наиболее серьезных примеров стало существование дубликата коммита, идентичного по содержанию оригиналу, но с другим хешем SHA1, который ложно включал подпись Линуса Торвальдса.
Эти изменения нельзя отнести просто к случайной ошибкеl во время операции git rebase, поскольку они включали в себя массовую модификацию конфиденциальной информации, включая более 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 и прозрачность процесса, ситуация взята под контроль.
Наконец, если вам интересно узнать об этом больше, вы можете проверить подробности в следующем ссылка.