Несколько дней назад произошёл необычный инцидент , потрясший сообщество разработчиков ядра Linux: Линус Торвальдс распорядился немедленно заблокировать учётную запись Киса Кука на kernel.org после обнаружения подделанных коммитов в репозитории Git этого разработчика.
Кис Кук, известный своим лидерством в команде безопасности Ubuntu и поддержкой более десятка подсистем, связанных с безопасностью ядра, был временно отстранен от внесения изменений до выяснения обстоятельств дела.
Изменение авторства и подписей в репозитории Киса Кука
Проблема возникла из-за запроса на внесение изменений в ветку ядра 6.16, в котором Линус обнаружил ссылки на репозиторий, содержащий измененные коммиты, где его имя было указано в качестве автора и подтверждающего лица, хотя он их не вносил. Одним из наиболее серьезных примеров было существование дубликата коммита, идентичного по содержанию оригиналу, но с другим хешем SHA1, который ошибочно включал подпись Линуса Торвальдса.
Эти изменения нельзя объяснить простой случайной ошибкой во время операции git rebase, поскольку они повлекли за собой масштабную модификацию конфиденциальной информации, включая более 6.000 переписанных коммитов, 330 из которых были указаны в качестве автора как Линус.
Реакция Торвальдса: подозрения в преднамеренной манипуляции
Линус Торвальдс не скрывал своей обеспокоенности и назвал произошедшее потенциально злонамеренным:
«Одна или две переписывания могли быть ошибкой. Но тысячи из них, многие с моей поддельной подписью, таковыми не являются», — заявил он.
Учитывая масштаб изменений и риск для целостности официального дерева исходного кода ядра, Торвальдс попросил Константина Рябицева, администратора инфраструктуры kernel.org, заблокировать доступ Киса Кука до выяснения ситуации.
В ответ Кис Кук объяснил, что недавно столкнулся с техническими проблемами , которые, возможно, и спровоцировали инцидент. Он заявил, что его SSD-накопитель вышел из строя во время операций копирования, что привело к повреждению данных в нескольких репозиториях. После этих ошибок он попытался восстановить состояние своего репозитория с помощью команды `git rebase` и различных инструментов автоматизации.
Однако эти операции были выполнены в критически важных ветвях , таких как for-next/hardening и for-linus/hardening, что привело к случайному изменению истории репозитория, включая изменения в авторстве коммитов. Несмотря на его объяснение, Линус остался скептиком.
«Я не понимаю, как мог произойти случайный обгон, тем более при таком объеме изменений».
Настоящий виновник: git-filter-repo и трейлеры b4
В последующем сообщении Кис Кук определил вероятную причину ошибки : совместное использование двух инструментов, git-filter-repo и b4 trailers, которые манипулируют историей коммитов и трейлерами (метками, такими как Signed-off-by:) в коммитах.
Такое неправильное использование утилит привело бы к автоматическому переписыванию тысяч коммитов , включая замену автора на значение по умолчанию (в данном случае, Линус Торвальдс), без того, чтобы Кис заметил ошибку в тот момент . Константин Рябицев, автор инструмента b4, подтвердил эту теорию и заявил, что со стороны Кука не было злого умысла. На самом деле, система уже генерировала предупреждения, которые игнорировались.
После выяснения обстоятельств доступ Киса Кука к kernel.org был восстановлен. В качестве превентивной меры было объявлено о включении в инструмент b4 новой проверки безопасности, которая предотвратит изменение коммитов, авторство которых не соответствует личности текущего пользователя. Это направлено на предотвращение подобных ошибок и защиту целостности исходного кода ядра.
Кис, со своей стороны, пообещал воссоздать затронутые ветки из отдельных патчей и тщательно проанализировать шаги, приведшие к ошибке. Хотя инцидент обострил отношения внутри команды разработчиков ядра, он также подчеркнул важность осторожного использования инструментов перезаписи истории, особенно в таких критически важных проектах, как ядро Linux.
Наконец, стоит отметить, что этот инцидент между Линусом Торвальдсом и Кисом Куком служит предупреждением об опасностях манипулирования историей коммитов, и что благодаря быстрому вмешательству команды kernel.org и прозрачности процесса ситуация была взята под контроль.
Наконец, если вас интересует более подробная информация, вы можете найти ее по следующей ссылке.