{"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\/novosti-interneta\/inczident-s-podmenoj-kommitov-v-vetke-yadra-linux-ot-kesa-kuka","title":{"rendered":"Incidente di sostituzione dei commit nel ramo del kernel Linux di Kesa Cook","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
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 \u00e8 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. <\/p>\n
Nel repository git gestito da Kesa erano presenti modifiche fittizie, in cui il campo autore e committer era indicato come «Linus Torvalds», ma Linus non le aveva aggiunte. Ad esempio, sotto il nome di Linus nella branch di Kesa c'era un commit che ripeteva un altro commit nella branch di Linus, ma con un diverso hash SHA1. Entrambi i commit sembrano identici, ad eccezione delle informazioni sulla firma. <\/p>\n
Le modifiche non somigliavano a un errore casuale durante l'operazione «git rebase», poich\u00e9 contenevano informazioni errate sull'autore del commit. Linus Torvalds ha ritenuto questo un segnale di potenziale attivit\u00e0 dannosa e ha avviato il blocco dell'accettazione di qualsiasi modifica da parte di Kesa, finch\u00e9 non si chiariscono le ragioni di tali manovre e si conferma che il sistema di Kesa non sia stato compromesso. <\/p>\n
Kesa ha risposto di non capire come potesse essere successo. Prima di ci\u00f2, aveva riscontrato problemi nel tentativo di unire pi\u00f9 branch git e aveva tentato di risolverli con l'operazione «git rebase», ma apparentemente ci\u00f2 non ha risolto i problemi. Tutto ci\u00f2 stava avvenendo sullo sfondo di un guasto dell'unit\u00e0 SSD, che mostrava errori durante la copia. Kesa pensava di aver ripristinato lo stato dei suoi repository dopo il guasto, ma a quanto pare non era cos\u00ec. Per ripristinare l'integrit\u00e0, Kesa intende ricreare le sue branch a partire da singoli patch. Come causa pi\u00f9 probabile della sostituzione dell'autore, Kesa considera un tentativo fallito di ripristinare il repository dopo il danno. <\/p>\n
Linus non \u00e8 stato soddisfatto di tale spiegazione, poich\u00e9, secondo lui, le modifiche alla cronologia dei commit nel repository di Kesa sembrano molto pi\u00f9 somigliare a un'azione intenzionale piuttosto che a un errore casuale. Il rebase della cronologia delle modifiche tramite l'operazione «git rebase» potrebbe spiegare la riscrittura del committer, ma Linus non riesce a capire come un'operazione «git rebase» possa essere stata effettuata per errore. <\/p>\n
La riscrittura di uno o due commit potrebbe ancora essere attribuita a un errore, ma nel repository di Kesa erano stati riscritti pi\u00f9 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\u00f9 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. <\/p>\n
Kesa ha assicurato a Linus di non averlo fatto di proposito e non avrebbe mai condotto esperimenti simili senza avvisare (ad esempio, un esperimento precedente che ha comportato conflitti di commit era stato concordato con Linus). Questa settimana ha eseguito diverse operazioni manuali sul repository e ora cercher\u00e0 di capire cosa sia andato storto e riprodurre il problema. Ad esempio, Kesa ha eseguito un'operazione di rebase per gli alberi git for-next\/hardening e for-linus\/hardening, utilizzando, a differenza delle precedenti operazioni simili, la branch «master» invece di rc2. Durante quest'operazione ha apportato modifiche agli script per il controllo delle richieste di push. <\/p>\n
Nota: Kesa Cook ha pubblicato un altro messaggio, in cui ha dichiarato che probabilmente il problema \u00e8 sorto a causa dell'uso dell'utilit\u00e0 «git-filter-repo», che svolge operazioni di riscrittura della storia dei commit nel repository, in combinazione con il comando «b4 trailers», destinato a recuperare 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":"