Линус Торвальдс потребовал от администратора kernel.org немедленно заблокировать учётную запись Кеса Кука, бывшего главного сисадмина kernel.org и лидера Ubuntu Security Team, сопровождающего в ядре 14 подсистем, связанных с безопасностью. Константин Рябцев, отвечающий за работу инфраструктуры kernel.org, выполнил блокировку. Поводом для блокировки послужил pull-запрос на включение в ветку ядра 6.16 изменений, ссылающийся на git-репозиторий, в котором была изменена информация об авторстве некоторых коммитов.
Estis ŝajnaj ŝanĝoj en la git-deponejo konservita de Kes, kiuj havis "Linus Torvalds" kiel la aŭtoron kaj ŝanĝon, sed Linus ne aldonis ilin. Ekzemple, estis ŝanĝo sub la nomo de Linus sur la branĉo de Kes, kiu estis duplikato de alia ŝanĝo sur la branĉo de Linus, sed kun malsama SHA1-haŝo. Ambaŭ ŝanĝoj aspektis identaj krom la subskribaj informoj.
La ŝanĝoj ne aspektis kiel hazarda eraro dum la operacio "git rebase", ĉar ili enhavis malĝustajn informojn pri la aŭtoro de la ŝanĝo. Linus Torvalds konsideris tion kiel pruvon de eble malica agado kaj iniciatis blokadon kontraŭ akcepto de iuj ajn ŝanĝoj de Kes ĝis la kialoj de tiaj manipuladoj estus determinitaj kaj la sistemo de Kes estus konfirmita ne esti kompromitita.
Kes respondis, ke li ne komprenas, kiel tio povus esti okazinta. Li antaŭe renkontis problemojn provante kunfandi plurajn el siaj git-branĉoj, kaj poste provis solvi ilin per operacio "git rebase", sed ŝajne tio ne helpis. Ĉio ĉi okazis kontraŭ la fono de kraŝinta SSD-disko, kiu donis erarojn dum kopiado. Kes kredis, ke li sukcesis restarigi la staton de siaj deponejoj post la kraŝo, sed ŝajne tio ne estas la kazo. Por restarigi integrecon, Kes intencas rekrei siajn branĉojn el individuaj flikaĵoj. Kes kredas, ke la plej verŝajna kialo por la aŭtora anstataŭigo, kiu okazis, estis malsukcesa provo restarigi la deponejon post ĝia difekto.
Lino ne kontentas pri ĉi tiu klarigo, ĉar li opinias, ke la ŝanĝoj al la historio de komisioj en la deponejo de Kes aspektas tre simile al konsciaj agoj, ne al hazarda fiasko. Rebazigi la historion de komisioj per "git rebase" povus klarigi la reverkadon fare de la komisiinto, sed Lino ne povas kompreni kiel tia "git rebase" povus esti farita erare.
La reverkado de unu aŭ du ŝanĝoj povus esti konsiderata eraro, sed la deponejo de Kes reverkis pli ol ses mil kunfandajn ŝanĝojn, el kiuj 330 havis Linus kiel la aŭtoron, kvankam tiuj ŝanĝoj ne devenis de la git-arbo de Linus. La faritaj ŝanĝoj aspektas pli kiel funkcianta skripto ol la rezulto de datenkorupto sur la disko, ĉar ili postulas apartan rekreon de kopio de ĉiu ŝanĝo.
Kes certigis al Linus, ke li ne faris tion intence kaj ne farus tiajn eksperimentojn sen averto (ekzemple, la antaŭa eksperimento por kaŭzi koliziojn de enigo-komisioj estis forigita per Linus). Li faris kelkajn manajn operaciojn en la deponejo ĉi-semajne kaj nun provos eltrovi, kio fuŝiĝis kaj reprodukti la problemon. Ekzemple, Kes rebazigis la git-arbojn for-next/hardening kaj for-linus/hardening, uzante la branĉon "master" anstataŭ rc2, male al antaŭaj rebazigoj. Li ankaŭ modifis la skriptojn por testi puŝajn petojn.
Ĝisdatigo: Kes Cook afiŝis alian mesaĝon deklarante, ke la problemon plej verŝajne kaŭzis la uzado de la ilo "git-filter-repo", kiu reskribas la historion de enkontiĝoj de deponejo, kune kun la komando "b4 trailers", kiu estas desegnita por akiri kaj apliki antaŭfilmojn al enkontiĝoj (ekz. "Subskribita de:").
fonto: opennet.ru
