Per chi si fosse perso la puntata precedente, negli scorsi giorni l’Università del Minnesota è stata bannata da qualsiasi tipo di collaborazione al Kernel Linux a seguito della pubblicazione di uno “studio” in cui alcuni studenti ammettevano di aver volutamente inserito delle vulnerabilità nelle patch che inviavano, per capire come avrebbe reagito la community.

Inutile dire che nessuno ha apprezzato la cosa e, oltre al ban, è stata prevista la rimozione di qualsiasi commit inviato dall’Università.

Il professore a capo dello “studio”, una figura da cui ci si aspetterebbe il blocco immediato di una ricerca del genere, ed i due studenti coinvolti hanno pensato di inviare una lettera di scuse.

Purtroppo una pessima scusa è peggio che scusarsi:

As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches.

Come molti ci hanno fatto notare, abbiamo commesso un errore non trovando un modo per confrontarci con la community ed ottenere il permesso prima di eseguire questo studio; lo abbiamo fatto perché sapevamo che non potevamo chiedere il permesso ai maintainers di Linux, altrimenti sarebbero andati alla ricerca di queste patch.

Lo pensa anche Greg Kroah-Hartman:

Thank you for your response.
As you know, the Linux Foundation and the Linux Foundation’s Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community.
Until those actions are taken, we do not have anything further to discuss about this issue.
thanks,

Grazie per la vostra risposta. Come sapete la Linux Foundation e la Linux Foundation Technical Advisory Board hanno inviato una lettera venerdì alla vostra Università delineando delle azioni specifiche da intraprendere in modo che il vostro gruppo e la vostra Università possa riguadagnare la fiducia della community del Kernel Linux. Fino a quando queste azioni non verranno intraprese, non abbiamo nulla di cui discutere. Grazie.

Le richieste della Linux Foundation sono semplici, tutto sommato:

Please provide to the public, in an expedited manner, all information necessary to identify all proposals of known-vulnerable code from any U of MN experiment. The information should include the name of each targeted software, the commit information, purported name of the proposer, email address, date/time, subject, and/or code, so that all software developers can quickly identify such proposals and potentially take remedial action for such experiments.

Fornite pubblicamente, in modo rapido, tutte le informazioni necessarie per identificare tutte le patch con vulnerabilità note di qualsiasi esperimento dell’Università del Minnesota. Le informazioni dovrebbero includere il nome di ogni software preso di mira, le informazioni del commit, il presunto nome di chi ha inviato la patch, indirizzo e-mail, data/ora, oggetto e/o codice, in modo che tutti gli sviluppatori possano identificare rapidamente tali patch ed eventualmente intraprendere azioni correttive per tali esperimenti.

Kroah-Hartman aveva individuato una lista di 190 patch di cui fare il revert ma, nonostante tutto, la community – dopo la giustificatissima arrabbiatura iniziale – ha deciso che non sarebbe stato utile eliminare i commit in massa, con la reale possibilità di reintrodurre vulnerabilità.

Un team di sviluppatori si è impegnato e revisionare le 190 patch e, fortunatamente, molte erano legittime; su 190 patch, quelle che verranno rimosse dal Kernel saranno 42 – che si tratta comunque del 22% circa.

La cosa che fa un po’ pensare gli sviluppatori è il fatto che comunque quelle patch malevole siano riuscite apassare il processo di approvazione finendo per essere inserite nel Kernel… e siano tuttora presenti. Le modifiche verranno probabilmente incluse nella prossima finestra di merge del Kernel 5.13.

Alla luce di tutto, sarebbe forse più appropriato rallentare gli sviluppi e dedicare più tempo alla review del codice?

Elena Metelli

Affascinata sin da piccola dai computer (anche se al massimo avevo un cluster di Mio Caro Diario), sono un’opensourcer per caso, da quando sono incappata in Mandrake. Legacy dentro. Se state leggendo un articolo amarcord, probabilmente l’ho scritto io.