{"id":125748,"date":"2025-06-01T15:05:12","date_gmt":"2025-06-01T13:05:12","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka"},"modified":"2025-06-01T15:05:12","modified_gmt":"2025-06-01T13:05:12","slug":"inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","status":"publish","type":"post","link":"https:\/\/prohoster.info\/nl\/blog\/news\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","title":{"rendered":"Incident van het vervangen van commits in de Linux-kernelbranch door Kesa Cook","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Linus Torvalds heeft de beheerder van kernel.org verzocht om onmiddellijk het account van Kesa Ku\u043a, de voormalige hoofd systeembeheerder van kernel.org en leider van het Ubuntu Security Team, te blokkeren. Kesa beheert 14 subsystemen in de kernel die verband houden met beveiliging. Konstantin Ryabtsev, verantwoordelijk voor de infrastructuur van kernel.org, heeft de blokkade uitgevoerd. De aanleiding voor de blokkade was een pull-verzoek om wijzigingen op te nemen in de kernel branch 6.16, dat verwijst naar een git-repository waarin informatie over het auteurschap van bepaalde commits was gewijzigd. <\/p>\n
In de door Kess ondersteunde git-repository waren er valse wijzigingen aanwezig, waarin als auteur en committer «Linus Torvalds» was opgegeven, maar Linus had deze niet toegevoegd. Bijvoorbeeld, onder de naam van Linus was er een commit in de tak van Kess die een andere commit in de tak van Linus herhaalde, maar met een andere SHA1-hash. Beide commits zien er identiek uit, behalve de handtekeninginformatie. <\/p>\n
De wijzigingen leken geen toevallige fout te zijn tijdens het uitvoeren van de «git rebase»-bewerking, omdat ze onjuiste informatie bevatten over de auteur van de commit. Linus Torvalds beschouwde dit als sporen van mogelijk kwaadaardige activiteiten en initieerde een blokkade voor het accepteren van wijzigingen van Kess, totdat de redenen voor dergelijke manipulaties waren opgehelderd en bevestigd dat Kess' systeem niet was gecompromitteerd. <\/p>\n
Kess antwoordde dat hij niet begrijpt hoe dit kon gebeuren. Eerder had hij problemen ondervonden bij het proberen samen te voegen van verschillende git-takken, waarna hij probeerde deze op te lossen met de «git rebase»-bewerking, maar het lijkt erop dat dit niet heeft geholpen. Dit alles vond plaats tegen de achtergrond van een SSD-storing, die fouten gaf tijdens het kopi\u00ebren. Kess geloofde dat hij na de storing de status van zijn repositories had kunnen herstellen, maar kennelijk is dit niet zo. Om de integriteit te herstellen, is Kess van plan zijn takken opnieuw te cre\u00ebren uit afzonderlijke patches. De meest waarschijnlijke oorzaak van de vervangingen van de auteur acht Kess een mislukte poging om de repository te herstellen na schade. <\/p>\n
Linus was niet tevreden met deze uitleg, omdat hij van mening was dat de wijzigingen in de geschiedenis van commits in Kess' repository sterk leken op opzettelijke acties en niet op een toevallige storing. Het opnieuw indelen van de geschiedenis door middel van de «git rebase»-bewerking zou de herschrijving van de committer kunnen verklaren, maar Linus kan niet begrijpen hoe een dergelijke «git rebase»-bewerking per ongeluk zou kunnen zijn uitgevoerd. <\/p>\n
Rewriting one or two commits could still be attributed to an error, but in Kess's repository, over six thousand merge commits were rewritten, of which Linus was set as the author for 330, despite the fact that these commits were not obtained from Linus\u2019s git tree. The changes made resemble the work of a script more than the result of data corruption on the storage, as they require a separate recreation of each commit. <\/p>\n
Kees verzekerde Linus dat hij dit niet opzettelijk had gedaan en dergelijke experimenten niet zonder waarschuwing zou uitvoeren (bijvoorbeeld, het vorige experiment met het oproepen van commitsbotsingen was goedgekeurd door Linus). Deze week voerde hij verschillende handmatige acties uit met de repository en zal nu proberen uit te zoeken wat er misging en het probleem te reproduceren. Zo voerde Kees een rebase-operatie uit voor de git-bomen for-next\/hardening en for-linus\/hardening, gebruikmakend van de «master»-branch, en niet van rc2 zoals bij eerdere vergelijkbare transformaties. Tijdens deze operatie bracht hij wijzigingen aan in de scripts voor het controleren van pull-requests. <\/p>\n
Aanvulling: Kees Cook publiceerde nog een bericht waarin hij verklaarde dat het probleem hoogstwaarschijnlijk is ontstaan door het gebruik van de tool «git-filter-repo», die de geschiedenis van commits in de repository herschrijft, in combinatie met de opdracht «b4 trailers», die bedoeld is om trailers aan commits te verkrijgen en toe te passen (bijvoorbeeld «Signed-off-by:»). \n Bron: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"