Linus Torvalds ha richiesto all'amministratore di kernel.org di bloccare immediatamente l'account di Kesa Kuka, ex amministratore di sistema di kernel.org e leader dell'Ubuntu Security Team, responsabile di 14 sottosistemi relativi alla sicurezza nel kernel. Konstantin Ryabtsev, responsabile delle infrastrutture di kernel.org, ha effettuato il blocco. La causa del blocco è stata una pull request per l'inclusione in 6.16 di modifiche che rimandavano a un repository git in cui era stata modificata l'informazione sull'autore di alcuni commit.
Nel repository git gestito da Kesa erano presenti modifiche fittizie, in cui il campo autore e committer conteneva "Linus Torvalds", ma Linus non le aveva aggiunte. Ad esempio, sotto il nome di Linus nel ramo di Kesa si trovava un commit che ripeteva un altro commit nel ramo di Linus, ma con un hash SHA1 diverso. Entrambi i commit sembrano identici, ad eccezione delle informazioni sulla firma.
Le modifiche non apparivano come un errore casuale durante l'operazione "git rebase", poiché contenevano informazioni errate sull'autore del commit. Linus Torvalds ha considerato questo come tracce di potenziale attività dannosa e ha avviato il blocco della ricezione di qualsiasi modifica da Kesa, fino a chiarire le motivazioni di tali manovre e confermare che il sistema di Kesa non fosse stato compromesso.
Kesa ha risposto di non comprendere come ciò potesse essere accaduto. Prima di questo, aveva riscontrato problemi nel tentativo di unire diversi rami git, dopo di che aveva cercato di risolverli con l'operazione "git rebase", ma sembra che questo non abbia aiutato. Tutto ciò avveniva in un contesto di guasto dell'unità SSD, che forniva errori durante la copia. Kesa pensava di essere riuscito a ripristinare lo stato dei suoi repository dopo il guasto, ma a quanto pare non era così. Per ripristinare l'integrità, Kesa ha intenzione di ricreare i suoi rami da patch separate. Come causa più probabile della sostituzione dell'autore, Kesa ritiene che possa trattarsi di un tentativo mal riuscito di ripristinare il repository dopo il suo danneggiamento.
A Linus non è piaciuta questa spiegazione, poiché ritiene che le modifiche nella cronologia dei commit nel repository di Kess siano molto simili a un'azione intenzionale, e non a un errore casuale. Il rebasing della cronologia delle modifiche tramite l'operazione "git rebase" potrebbe spiegare la riscrittura del commit, 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 Kess sono stati riscritti più di seimila commit di merge, di cui in 330 il creatore è stato Linus, mentre quei commit non sono stati ottenuti dall'albero git di Linus. Le modifiche effettuate somigliano più al lavoro di uno script che a un risultato di danneggiamento delle informazioni su disco, in quanto richiedono una ricreazione separata di ogni commit.
Kess ha assicurato a Linus che non l'ha fatto intenzionalmente e non avrebbe condotto esperimenti simili senza avvisare (ad esempio, il precedente esperimento sulle collisioni dei commit era stato concordato con Linus). Questa settimana ha eseguito diverse operazioni manuali sul repository e ora cercherà di capire cosa sia andato storto e replicare il problema. Ad esempio, Kess ha eseguito l'operazione rebase sugli alberi git for-next/hardening e for-linus/hardening, utilizzando, a differenza di precedenti trasformazioni simili, il ramo "master", invece di rc2. Durante questa operazione, ha apportato modifiche agli script per verificare le richieste push.
Nota: Kess Cook ha pubblicato un altro messaggio, in cui ha dichiarato che la probabile causa del problema è l'uso dello strumento "git-filter-repo", che esegue la riscrittura della cronologia dei commit nel repository, in combinazione con il comando "b4 trailers", destinato a ottenere e applicare i trailer ai commit (ad esempio, "Signed-off-by:").
Fonte: opennet.ru
