{"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\/it\/blog\/news\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","title":{"rendered":"L'incidente relativo alla sostituzione di commit nel ramo del kernel Linux da parte di Kesa Kuka","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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 \u00e8 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. <\/p>\n
Nel repository git supportato da Kess erano presenti modifiche fittizie, nel cui campo autore e committer era indicato \u00abLinus Torvalds\u00bb, ma Linus non le aveva aggiunte. Ad esempio, a nome di Linus nel branch di Kess c'era un commit che ripeteva un altro commit nel branch di Linus, ma con un hash SHA1 diverso. Entrambi i commit appaiono identici, tranne per le informazioni sulla firma. <\/p>\n
Le modifiche non sembravano un errore casuale durante l'esecuzione dell'operazione \u00abgit rebase\u00bb, poich\u00e9 contenevano informazioni errate sull'autore del commit. Linus Torvalds ha considerato ci\u00f2 come segni di potenziale attivit\u00e0 dannosa e ha avviato il blocco della ricezione di qualsiasi modifica da Kess fino a chiarire le ragioni di tali manovre e confermare che il sistema di Kess non fosse stato compromesso. <\/p>\n
Kess ha risposto dicendo di non capire come potesse essere successo. Prima aveva riscontrato problemi nel tentativo di unire diversi branch git, dopo di che ha provato a risolverli con l'operazione \u00abgit rebase\u00bb, ma apparentemente questo non ha aiutato. Tutto ci\u00f2 accadeva in un contesto di guasto dell'unit\u00e0 SSD, che mostrava errori durante il trasferimento. Kess pensava di essere riuscito a ripristinare lo stato dei suoi repository dopo il guasto, ma a quanto pare non \u00e8 cos\u00ec. Per ripristinare l'integrit\u00e0, Kess intende ricreare i suoi branch da singoli patch. Come causa pi\u00f9 probabile della sostituzione dell'autore, Kess considera un tentativo fallito di ripristino del repository dopo il suo danneggiamento. <\/p>\n
Linus non ha trovato soddisfacente tale spiegazione, poich\u00e9, a suo avviso, le modifiche nella cronologia dei commit nel repository di Kess sembrano molto simili a un'azione intenzionale, piuttosto che a un errore casuale. Il rebase della cronologia delle modifiche tramite l'operazione \u00abgit rebase\u00bb potrebbe spiegare la riscrittura del committer, ma Linus non riesce a capire come un'operazione \u00abgit rebase\u00bb simile possa essere stata eseguita per errore. <\/p>\n
La riscrittura di uno o due commit potrebbe ancora essere attribuita a un errore, ma nel repository di Kess sono stati riscritti pi\u00f9 di seimila commit di merge, di cui in 330 il creatore \u00e8 stato Linus, mentre quei commit non sono stati ottenuti dall'albero git di Linus. Le modifiche effettuate somigliano pi\u00f9 al lavoro di uno script che a un risultato di danneggiamento delle informazioni su disco, in quanto richiedono una ricreazione separata di ogni commit. <\/p>\n
Kess ha assicurato a Linus che non lo ha fatto intenzionalmente e non avrebbe mai condotto esperimenti simili senza avvisare (per esempio, l'esperimento precedente sulle collisioni nei commit era stato concordato con Linus). Questa settimana ha eseguito alcune operazioni manuali con il repository e ora cercher\u00e0 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, utilizzando, a differenza di trasformazioni simili precedenti, il ramo \"master\" invece di rc2. Durante questa operazione ha apportato modifiche agli script per verificare le richieste di push. <\/p>\n
Nota: Kess Cook ha pubblicato un altro messaggio in cui afferma che probabilmente il problema \u00e8 sorto a causa dell'uso dell'utilit\u00e0 \"git-filter-repo\", che esegue la riscrittura della cronologia dei commit nel repository, insieme al comando \"b4 trailers\", che \u00e8 destinato a ottenere e applicare i trailer ai commit (ad esempio, \"Signed-off-by:\"). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"