Linus Torvalds ha chiesto all'amministratore di kernel.org di bloccare immediatamente l'account di Kesa Cook, ex amministratore di sistema di kernel.org e leader del Ubuntu Security Team, che gestisce 14 sottosistemi relativi alla sicurezza nel kernel. Konstantin Ryabtsev, responsabile dell'infrastruttura di kernel.org, ha eseguito il blocco. La motivazione del blocco è stata una richiesta di integrazione nella branch del kernel 6.16 che faceva riferimento a un repository git in cui erano state modificate le informazioni sugli autori di alcuni commit.
Nel repository git supportato da Kess erano presenti modifiche fittizie, nei dettagli dell'autore e del mittente delle quali era indicato "Linus Torvalds", ma Linus non le aveva aggiunte. Ad esempio, a nome di Linus in un ramo di Kess c'era un commit che ripeteva un altro commit nel ramo di Linus, ma con un diverso hash SHA1. Entrambi i commit sembrano identici, tranne per le informazioni sulla firma.
Le modifiche non sembravano un errore casuale durante l'operazione di "git rebase", poiché contenevano informazioni errate sull'autore del commit. Linus Torvalds considerò ciò come segni di potenziale attività dannosa e avviò il blocco dell'accettazione di qualsiasi modifica da parte di Kess, fino a chiarire le motivazioni di tali manovre e confermare che il sistema di Kess non fosse stato compromesso.
Kess ha risposto di non capire come potesse essere successo. In precedenza aveva incontrato problemi nel tentativo di unire diversi rami git, dopo di che ha cercato di risolverli con l'operazione di "git rebase", ma apparentemente non ha funzionato. Tutto ciò stava accadendo in un contesto di guasto dell'unità SSD, che mostrava errori durante la copia. Kess credeva di essere riuscito a ripristinare lo stato dei propri repository dopo il guasto, ma a quanto pare non è così. Per ripristinare l'integrità, Kess intende ricreare i propri rami da patch separate. Come causa più probabile della sostituzione dell'autore, Kess considera un tentativo fallito di ripristinare il repository dopo il suo danneggiamento.
Linus non ha accettato tale spiegazione, poiché riteneva che le modifiche alla cronologia dei commit nel repository di Kess somigliassero molto a un'azione intenzionale e non a un errore casuale. Il ri-base della cronologia delle modifiche tramite l'operazione di "git rebase" potrebbe spiegare la sovrascrittura del mittente, ma Linus non riesce a capire come un'operazione di "git rebase" possa essere stata eseguita per errore.
La riscrittura di uno o due commit potrebbe ancora essere attribuita a un errore, ma nel repository di Kesa erano stati riscritti più di seimila merge commit, di cui 330 avevano Linus come autore, mentre quei commit non erano stati ottenuti dall'albero git di Linus. Le modifiche effettuate somigliano di più all'operato di uno script piuttosto che a un risultato di danni alle informazioni sul dispositivo, in quanto richiedono la ricreazione separata di ogni single commit.
Kess ha assicurato a Linus che non l'ha fatto intenzionalmente e non avrebbe condotto esperimenti del genere senza preavviso (ad esempio, il precedente esperimento per provocare collisioni nei commit era stato concordato con Linus). Questa settimana ha eseguito diverse operazioni manuali con il repository e ora cercherà di capire cosa sia andato storto e riprodurre il problema. Ad esempio, Kess ha eseguito un'operazione di rebase per gli alberi git for-next/hardening e for-linus/hardening, usando, a differenza delle precedenti operazioni simili, il ramo "master" anziché rc2. Durante questa operazione ha apportato modifiche agli script per il controllo delle richieste push.
Supplemento: Kess Cook ha pubblicato un ulteriore messaggio in cui afferma che probabilmente il problema è sorto a causa dell'uso dell'utility "git-filter-repo", che esegue la riscrittura della cronologia dei commit nel repository, insieme al comando "b4 trailers", destinato a ottenere e applicare i trailer ai commit (ad esempio, "Signed-off-by:").
Fonte: opennet.ru
