
Un nuovo episodio di tensione nello sviluppo del kernel Linux? Sì, ma è stato gestito.
A questo punto, è noto che lo sviluppo del kernel Linux è un’impresa colossale portata avanti da migliaia di contributori e, non di rado, le tensioni salgono, portando a scambi di parole piuttosto aspri.
Tali eventi possono essere considerati parte del processo quando si lavora su un progetto enorme e complesso come il kernel Linux.
Un recente episodio serve come promemoria di quanto le cose possano diventare intense.
Il Guardiano del kernel Linux si sveglia
Esprimendo preoccupazione per l’insieme di modifiche (un insieme di patch) di un contributore del kernel Linux, Linus Torvalds ha redarguito Kees Cook per aver inviato 330 richieste di integrazione che copiavano le patch di Torvalds stesso e lo indicavano nuovamente come autore.
Ha definito la mossa “attivamente maligna”, indicando operazioni di unione contraffatte che includevano firme SHA-1 (Secure Hash Algorithm 1, un algoritmo di hashing crittografico) errate. Ad esempio, una patch legittima di Torvalds aveva una firma SHA-1 che iniziava con 9d230d500b0e, mentre la versione duplicata/falsa inviata da Kees usava f8b59a0f90a2.
Poco dopo, Kees ha chiarito cosa potrebbe essere andato storto, attribuendo il problema a un’unità a stato solido (SSD) difettosa che aveva generato errori durante il trasferimento dei dati, risultando in un insieme di modifiche corrotte e unioni danneggiate. Si è scusato e ha accettato di eliminare l’insieme delle modifiche interessate, impegnandosi a ricostruire l’insieme di patch in modo pulito prima di reinviarle.
Tuttavia, Linus Torvalds non si è convinto della spiegazione fornita da Kees Cook. Era difficile per lui credere che un cambiamento così grande nei dati delle modifiche potesse accadere per sbaglio. Normalmente, Git, che è uno strumento utilizzato per gestire le diverse versioni del codice sorgente, si occupa di aggiornare automaticamente i dettagli su chi ha effettuato le modifiche durante le operazioni di aggiornamento e fusione del codice. Linus ha pensato che, per ottenere un risultato come quello osservato, fosse probabilmente necessario l’uso di uno script, ovvero un programma automatico, che avesse alterato i dati in modo non casuale.
Kees Cook ha ribadito di non aver agito intenzionalmente, spiegando che il problema era stato causato da una combinazione di fattori: un’unità a stato solido (SSD) danneggiata, un processo manuale di aggiornamento del codice particolarmente complesso e alcuni controlli di sicurezza che erano stati accidentalmente disattivati.
Dopo alcune discussioni tra Kees Cook, Linus Torvalds e Konstantin Ryabitsev, è emerso che il problema principale era dovuto a un errore dello strumento B4. Questo strumento, utilizzato per gestire le modifiche al codice, aveva accidentalmente cambiato alcune informazioni chiave, come i dati su chi aveva effettuato le modifiche, durante un’operazione di aggiornamento della storia delle modifiche stesse.
Grazie alla comunicazione “per lo più civile” e molto costruttiva tra tutte le parti coinvolte, il problema è stato risolto e, in tutto ciò, una cosa è stata resa chiara: Linus Torvalds è il guardiano vigile del kernel Linux, qualcuno che, sebbene facilmente irritabile, è sempre all’erta.
Per chi fosse interessato a conoscere più dettagli sull’argomento, è possibile leggere l’intera discussione online.
Fonte: https://lore.kernel.org/all/20250601-wandering-graceful-crane-ffc0b7@lemur/t.atom
Fonte: https://howtouselinux.medium.com/linus-torvalds-just-called-out-330-unexpected-commits-during-kernel-merge-2ff04d45db76
Fonte: https://news.itsfoss.com/linus-kernel-broken-pull-request/
Source: Read More