Incident van het vervangen van commits in de Linux-kernelbranch door Kesa Cook

Linus Torvalds heeft de beheerder van kernel.org verzocht om onmiddellijk het account van Kesa KuŠŗ, 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.

In de door Kesa ondersteunde git-repository waren er valse wijzigingen, waarbij 'Linus Torvalds' als auteur en committer was opgegeven, maar Linus deze niet had toegevoegd. Bijvoorbeeld, onder de naam van Linus was er een commit in Kesa's branch die een andere commit in Linus' branch herhaalde, maar met een andere SHA1-hash. Beide commits lijken identiek, op de handtekeninginformatie na.

De wijzigingen leken geen toevallige fout te zijn bij het uitvoeren van de 'git rebase'-bewerking, aangezien ze onjuiste informatie over de auteur van de commit bevatten. Linus Torvalds beschouwde dit als aanwijzingen voor potentieel kwaadaardige activiteiten en initieerde de blokkering van het accepteren van wijzigingen van Kesa, totdat de oorzaken van dergelijke manipulaties zijn verduidelijkt en bevestigd is dat Kesa's systeem niet was gecompromitteerd.

Kesa antwoordde dat hij niet begrijpt hoe dit kon gebeuren. Hij had eerder problemen ondervonden bij het samenvoegen van verschillende git-branches, waarna hij probeerde deze op te lossen met de 'git rebase'-bewerking, maar het lijkt erop dat dit niet hielp. Dit alles vond plaats tegen de achtergrond van een storing van de SSD-opslag, die fouten gaf bij het kopiƫren. Kesa dacht dat hij na de storing de toestand van zijn repositories had hersteld, maar kennelijk is dat niet het geval. Om de integriteit te herstellen, is Kesa van plan zijn branches opnieuw te creƫren uit afzonderlijke patches. Hij beschouwt een mislukte poging om de repository te herstellen na de schade als de meest waarschijnlijke oorzaak van de vervalsing van de auteur.

Linus was not satisfied with this explanation, as he believed that the changes in the commit history of Kess’s repository closely resembled intentional actions rather than an accidental failure. Rebasing the change history with the ā€˜git rebase’ operation could explain the rewriting of the committer, but Linus cannot understand how such a ā€˜git rebase’ operation could have been performed by mistake.

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’s 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.

Kess assured Linus that he did not do this intentionally and would not conduct such experiments without prior notice (for example, the previous experiment regarding commit collisions was agreed upon with Linus). This week he performed several manual operations with the repository and will now attempt to figure out what went wrong and reproduce the issue. For instance, Kess executed a rebase operation for the git trees for-next/hardening and for-linus/hardening, using the 'master' branch instead of rc2 as he did in past similar transformations. During this operation, he modified scripts to check for pull requests.

Addition: Kess Cook published another message stating that the problem likely arose from using the ā€˜git-filter-repo’ utility, which rewrites the commit history in the repository, combined with the command ā€˜b4 trailers’, intended for obtaining and applying trailers to commits (for example, ā€˜Signed-off-by:’).

Bron: opennet.ru

Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers šŸ”„ Koop betrouwbare webhosting met bescherming tegen DDoS, VPS VDS servers | ProHoster