Le scuse non bastano, la pace tra l'Università del Minnesota e Linux passa da azioni ben precise

[LMCH]

Penso che un ulteriore motivo per cui gli sviluppatori si sono incazzati di brutto, è che la "ricerca" serviva solo a ri-scoprire l'acqua calda.

È OVVIO che una code review per quanto fatta con cura non garantisce al 100% che non ci siano bug o vulnerabilità introdotte ad hoc.

Non a caso uno dei vantaggi del software open source è che nel tempo c'è molta più gente che analizza il codice o lo ispeziona dopo aver notato qualcosa di strano; non è una garanzia che il software sia "perfetto", ma statisticamente è più probabile che eventuali bug o falle vengano identificati e patchati.

[Ago72]

Originariamente inviato da Sp3cialFx

Ci sono due questioni distinte:
- le questioni etiche legate alle modalità svolte dalla ricerca, sulle quali non credo di avere sensibilità / competenze per entrare nel merito quindi passo oltre
- l'evidenza che sia stato tutto sommato semplice compromettere la sicurezza del kernel

I due aspetti dovrebbero andare trattati entrambi;

Infatti, ma essendo entrambi colpevoli, l'unica cosa che possono fare è buttarla in caciara.

[Pino90]

Originariamente inviato da cerbert

Tralasciando i contributi di chi non completa la lettura di un articolo in lingua italiana ma commenta l'efficienza di revisori esperti su codice C/C++ il fatto che a me leggermente inquieta di queste scuse è che arrivano dai ricercatori ma non dal professore responsabile della ricerca, che avrebbe dovuto essere mentore e consigliere su come si conduce eticamente una ricerca che coinvolge persone.
.

Originariamente inviato da zephyr83

due possibili ipotesi, analfabetismo funzionale oppure "voglia di commentare senza aver letto la notiza"

Io suggerirei di leggere la notizia su altra fonte così, tanto per confermare che effettivamente il processo di revisione ha funzionato. Il primo stage di revisione ha fatto passare la patch, al secondo (con i revisori appunto senior e l'inclusione in un tree) le falle di sicurezza sono state beccate.

Io sarò analfabeta, ma stranamente la notizia è riportata male e da qualcuno che forse non conosce il processo di submit. Prima di dare dell'analfabeta funzionale sarebbe carino magari chiedere le fonti che Manolo non ha riportato.

Grazie per gli insulti gratuiti, cafoni maleducati!

Originariamente inviato da Sp3cialFx

le alternative sono due:

- o sono scemo che non so leggere l'italiano
- oppure ho letto la storia altrove (dove probabilmente l'ha letta l'autore dell'articolo - le testate serie riportano la fonte, sapete?) in cui viene specificata meglio la cronologia degli eventi.

I ricercatori hanno fatto in tempo a pubblicare i risultati raggiunti ("vulnerabilità immature" e patch per farle diventare vulnerabilità vere e proprie) al "42nd IEEE Symposium on Security and Privacy". A febbraio.

Settimana scorsa ( https://lkml.org/lkml/2021/4/21/454 ) è stato fatto il revert. Dopo 2 mesi. Ma soprattutto dopo 2 mesi DOPO CHE E' STATO RESO VOLONTARIAMENTE TUTTO PUBBLICO. Se aprite il link è tutto riportato lì (tranne che il simposio si è tenuto a febbraio. Quello è stato omesso).

Ora ditemi nuovamente come funziona bene la procedura e come i dev si siano accorti tempestivamente della cosa.

Hai preso solo l'ultima parte della storia. Esiste un intero thread che va avanti da sei mesi sul tema delle patch e il thread è culminato con la sclerata di Greg K-L in cui si annunciava che da ora in poi saranno rigettate tutte le patch by default.

Il processo di sottomissione di una patch è piuttosto lungo (normalmente ci vogliono mesi o anni per arrivare in mainline) e loro hanno compromesso il primo anello, ossia quello della mailing list.
Praticamente si chiede ad un revisore "junior" un feedback sul codice. Il feedback non ha alcuna valenza tecnica in quanto il revisore in questione non ha il compito di "accettare" o "rigettare" un commit; praticamente gli da una occhiata, si occupa di cercare "bad practices" e le classiche cose che vengono poi rigettate quando si arriva alla sottomissione vera e propria, con un revisore "senior" in quell'aspetto o funzione specifica dell'OS. Il ruolo di queste persone è fondamentalmente di fare una prima scrematura del codice per poi anche ai nabbi volendo di partecipare alla stesura dell'OS. Se la patch viene fatta passare, normalmente finisce nell'albero (tree) di qualche maintainer, che di solito ha vari anni di esperienza in quell'aspetto specifico dell'OS. Il maintainer ha una sua mailing list dove si discute del codice e di come procedere con lo sviluppo, di quale codice accettare e di quale rigettare. Di fatto c'è un gruppo di persone che analizza quel codice e ne discute. In questo caso il maintainer è Greg K-H di cui si accennava sopra. Greg si è accorto a gennaio dei problemi e infatti ci sono thread e thread di email in cui se ne parla.
Per completare il processo, una volta che il maintainer decide che il lavoro può essere unito al mainline viene creata una patch di merging che viene sottoposta al team di Linus che ha l'ultima parola a riguardo.

I "ricercatori" sono arrivati alla mailing list e all'attenzione di un maintainer, che infatti si è anche scocciato parecchio a Gennaio per la qualità del codice e i suoi numerosi problemi (basta rileggere le mail che guarda caso sono pubbliche). Dopo la scalata mediatica di questi furbacchioni quello che hanno ottenuto è il ban della intera università e il revert di tutte le loro patch.

Insomma per fare un esempio terra terra ci si lamenta della sicurezza di un palazzo perchè i ladri hanno scavalcato il muretto, senza contare portone, portiere e porta blindata.

Un esempio sulle lungaggini e la cura che c'è dietro il codice posso portarlo dall'esperienza personale: io ho iniziato a lavorare sul /arch/arm64/kvm/ quando il kernel stava alla 4.19. Il mio lavoro è arrivato in mainline quando il kernel è arrivato alla 5.8 rc2, cioé praticamente due anni più tardi, nonostante io abbia impiegato solo tre mesi a scrivere tutto il codice.



A differenza di tutti i cafoni che mi hanno dato dell'analfabeta funzionale e sottilmente dell'imbecille, conosco molto bene il processo di sottomissione essendo parte del mio lavoro e quindi, almeno dalla mia prospettiva, ha funzionato bene. Basta andare a leggere per vedere le prove, ma capisco che addirittura fare una ricerca prima di dare aria alla bocca per quattro hater funzionali sia troppo.

Originariamente inviato da Manolo De Agostini

In pratica il codice buggato, o vulnerabile, non è finito nel kernel perché i ricercatori hanno "svelato il bluff". Tutto il resto rimane invece così com'è.

Quello è il primo stage. Dalla inclusione nel tree di un maintainer al mainlining passano anni normalmente e revisioni di più e più persone.

[zephyr83]

Originariamente inviato da Pino90

Io suggerirei di leggere la notizia su altra fonte così, tanto per confermare che effettivamente il processo di revisione ha funzionato. Il primo stage di revisione ha fatto passare la patch, al secondo (con i revisori appunto senior e l'inclusione in un tree) le falle di sicurezza sono state beccate.

Io sarò analfabeta, ma stranamente la notizia è riportata male e da qualcuno che forse non conosce il processo di submit. Prima di dare dell'analfabeta funzionale sarebbe carino magari chiedere le fonti che Manolo non ha riportato.

Grazie per gli insulti gratuiti, cafoni maleducati!



Hai preso solo l'ultima parte della storia. Esiste un intero thread che va avanti da sei mesi sul tema delle patch e il thread è culminato con la sclerata di Greg K-L in cui si annunciava che da ora in poi saranno rigettate tutte le patch by default.

Il processo di sottomissione di una patch è piuttosto lungo (normalmente ci vogliono mesi o anni per arrivare in mainline) e loro hanno compromesso il primo anello, ossia quello della mailing list.
Praticamente si chiede ad un revisore "junior" un feedback sul codice. Il feedback non ha alcuna valenza tecnica in quanto il revisore in questione non ha il compito di "accettare" o "rigettare" un commit; praticamente gli da una occhiata, si occupa di cercare "bad practices" e le classiche cose che vengono poi rigettate quando si arriva alla sottomissione vera e propria, con un revisore "senior" in quell'aspetto o funzione specifica dell'OS. Il ruolo di queste persone è fondamentalmente di fare una prima scrematura del codice per poi anche ai nabbi volendo di partecipare alla stesura dell'OS. Se la patch viene fatta passare, normalmente finisce nell'albero (tree) di qualche maintainer, che di solito ha vari anni di esperienza in quell'aspetto specifico dell'OS. Il maintainer ha una sua mailing list dove si discute del codice e di come procedere con lo sviluppo, di quale codice accettare e di quale rigettare. Di fatto c'è un gruppo di persone che analizza quel codice e ne discute. In questo caso il maintainer è Greg K-H di cui si accennava sopra. Greg si è accorto a gennaio dei problemi e infatti ci sono thread e thread di email in cui se ne parla.
Per completare il processo, una volta che il maintainer decide che il lavoro può essere unito al mainline viene creata una patch di merging che viene sottoposta al team di Linus che ha l'ultima parola a riguardo.

I "ricercatori" sono arrivati alla mailing list e all'attenzione di un maintainer, che infatti si è anche scocciato parecchio a Gennaio per la qualità del codice e i suoi numerosi problemi (basta rileggere le mail che guarda caso sono pubbliche). Dopo la scalata mediatica di questi furbacchioni quello che hanno ottenuto è il ban della intera università e il revert di tutte le loro patch.

Insomma per fare un esempio terra terra ci si lamenta della sicurezza di un palazzo perchè i ladri hanno scavalcato il muretto, senza contare portone, portiere e porta blindata.

Un esempio sulle lungaggini e la cura che c'è dietro il codice posso portarlo dall'esperienza personale: io ho iniziato a lavorare sul /arch/arm64/kvm/ quando il kernel stava alla 4.19. Il mio lavoro è arrivato in mainline quando il kernel è arrivato alla 5.8 rc2, cioé praticamente due anni più tardi, nonostante io abbia impiegato solo tre mesi a scrivere tutto il codice.



A differenza di tutti i cafoni che mi hanno dato dell'analfabeta funzionale e sottilmente dell'imbecille, conosco molto bene il processo di sottomissione essendo parte del mio lavoro e quindi, almeno dalla mia prospettiva, ha funzionato bene. Basta andare a leggere per vedere le prove, ma capisco che addirittura fare una ricerca prima di dare aria alla bocca per quattro hater funzionali sia troppo.



Quello è il primo stage. Dalla inclusione nel tree di un maintainer al mainlining passano anni normalmente e revisioni di più e più persone.

what? ma guarda che mica ho dato a te dell'analfabeta funzionale o uno che non le legge le notizie, anche se con la tua risposta il dubbio potrebbe venirmi. ho quotato te per darti ragione

[Sp3cialFx]

Pino90: grazie del contributo.

Ecco, abbiamo visto tre livelli di approfondimento della notizia:
- ci si ferma a una fonte
- si va a consultare più fonti
- si va all'origine / si è al dentro della questione

Io sono arrivato alla due e toccando in un solo punto la tre andando a vedere un singolo post;
Pino90 ha dato un contributo molto più approfondito e che dà una visione reale e completa della questione.

..che è diversa dall'idea che mi ero fatto, avevo torto; è sempre un momento di crescita quando qualcuno porta argomenti che superano quelli che hai, per lo meno se poi li fai propri, quindi ancora grazie. Bonus: ora sono anche anche più tranquillo sul processo di approvazione dei commit.

zephyr83: tu hai dato dell'AF a me che mi sono fermato al punto due mentre tu ti sei fermato al contenuto di un singolo articolo (che poi è stato corretto, cosa sempre apprezzata), reputo sia il caso di tacere.

[phmk]

Medaglia ai prof. ed agli studenti....
Inattaccabile Linux ...

[sisko214]

Stà roba non ha giustificazioni, le scuse se le possono mettere dove dico io.
Vanno bannati per l'eternità, così il prossimo che gli viene in mente di fare una cavolata del genere ci penserà su cinque volte prima.

[Pino90]

@Svelgen Qua i discorsi sono a vari livelli. Il primo è di natura etica, affrontato egregiamente in [1] e soprattutto da Laura Abbot (sviluppatrice del kernel con molta esperienza) in [2].
Il secondo è di natura materiale: ci vuole tempo e denaro per sistemare quanto fatto da queste persone.
Il terzo è esemplare, ossia si vuole dare un messaggio a tutte le istituzioni che vogliano fare qualcosa di simile. Infatti il problema più grande a mio avviso è che l'IRB (Institute Research Board) dell'università non ci ha trovato niente di male nelle azioni dei ricercatori, e le ha avallate.

L'ultimo punto è di merito della ricerca (che si può leggere gratuitamente in [3] e [4]): i tre ricercatori hanno svolto una ricerca in due parti. La prima è di carattere storico, una sorta di speleologia dello storico del codice del kernel in particolare riguardo a commit problematici. Questa prima parte ha concluso come da [1] che diversi "hypocrite commits" hanno già raggiunto il kernel negli ultimi anni, ossia il processo di revisione non è infallibile e va migliorato sia inserendo revisori nuovi (come chiesto a più riprese da tanti, incluso Greg Kroah-Hartman soggetto di questa news) sia usando strumenti di analisi statica.

La seconda parte consisteva nel tentare di bucare intenzionalmente il processo di revisione del codice per mostrare che non è infallibile. La cosa è rimane di dubbia utilità visto che la stessa conclusione non solo è lapalissiana e condivisa da buona parte della community, ma era già stata mostrata dalla parte 1 della ricerca. Di conseguenza appare:
1) ad alto rischio, sia etico che materiale
2) a basso rendimento, in quanto non apporta nessun risultato nuovo rispetto al lavoro già svolto dai tre revisori

E' ovviamente possibile migliorare lo studio, ma purtroppo i ricercatori sono andati per la strada del sensazionalismo. Fra le varie azioni per mitigare i rischi:

1) fare il commit di un errore di ortografia o di sintassi o comunque un "typo" innoquo. Continua ad essere una azione dalla dubbia morale visto che si continua ad ingannare i maintainer e a perdere il loro tempo, ma almeno i danni materiali sono limitati.

2) Informare l'organizzazione e ottenere il suo appoggio, un poco come avviene nelle aziende con i conratti di "pentesting". Questo avrebbe mitigato sia il rischio materiale che quello morale e francamente è incomprensibile perché non abbiano intrapreso questa strada.

3) Clonare il repo e chiedere ai maintainers di impiegare il loro tempo per controllare un set di commit creato ad hoc in modo da simulare la situazione.

Ovviamente intraprendere qualcuna di queste azioni avrebbe potuto minare la fedeltà dei risultati ma il punto è chequeste azioni non aggiungo nulla di nuovo rispetto alla prima parte della ricerca stessa.


[1] https://davisjam.medium.com/ethical-...h-86d13b6b6eed
[2] https://www.labbott.name/blog/2021/0...kingtrust.html
[3] https://github.com/QiushiWu/QiushiWu...Insecurity.pdf
[4] https://www-users.cs.umn.edu/~kjlu/p...cations-hc.pdf

Originariamente inviato da zephyr83

what? ma guarda che mica ho dato a te dell'analfabeta funzionale o uno che non le legge le notizie, anche se con la tua risposta il dubbio potrebbe venirmi. ho quotato te per darti ragione

Scusa, poteva essere frainteso e ovviamente ho frainteso.

[WarSide]

Originariamente inviato da phmk

Medaglia ai prof. ed agli studenti....
Inattaccabile Linux ...

Tu sei uno di quelli che non usa android e/o router/modem? Ti connetti ad internet col pensiero?

Sai che il tuo super PC windows con hw di ultima generazione al suo interno ha componenti (esempio la sk di rete integrata nella mobo) che fanno girare una versione minimale del kernel linux?

Se poi sei uno di quelli che si eccita ad essere bucato, beh, son gusti personali

[pabloski]

Originariamente inviato da phmk

Medaglia ai prof. ed agli studenti....
Inattaccabile Linux ...

Meglio le backdoor della NSA di cui si viene a sapere solo perchè qualche volenteroso ha cantato dopo decenni?

[zephyr83]

Originariamente inviato da Sp3cialFx

Pino90: grazie del contributo.

Ecco, abbiamo visto tre livelli di approfondimento della notizia:
- ci si ferma a una fonte
- si va a consultare più fonti
- si va all'origine / si è al dentro della questione

Io sono arrivato alla due e toccando in un solo punto la tre andando a vedere un singolo post;
Pino90 ha dato un contributo molto più approfondito e che dà una visione reale e completa della questione.

..che è diversa dall'idea che mi ero fatto, avevo torto; è sempre un momento di crescita quando qualcuno porta argomenti che superano quelli che hai, per lo meno se poi li fai propri, quindi ancora grazie. Bonus: ora sono anche anche più tranquillo sul processo di approvazione dei commit.

zephyr83: tu hai dato dell'AF a me che mi sono fermato al punto due mentre tu ti sei fermato al contenuto di un singolo articolo (che poi è stato corretto, cosa sempre apprezzata), reputo sia il caso di tacere.

io ho detto che le opzioni sono due, o non si arriva in fondo all'articolo oppure si è analfabeti funzionali perché non capiscono cosa leggono. io la notizia già la conoscevo, hwupgrade come al solito arriva tardi e c'è bisogno del contributo degli utenti per correggere la notizia.

[Manolo De Agostini]

Originariamente inviato da Pino90

Quello è il primo stage. Dalla inclusione nel tree di un maintainer al mainlining passano anni normalmente e revisioni di più e più persone.

Ciao, grazie del contributo prezioso. Ahimè tutte le fonti consultate (più di una, non ne prendo mai una, salvo quando è una per forza) - anche autorevoli o di settore Linux - hanno semplificato o non riportato i passaggi del processo di revisione, e questo ha comportato un po' di confusione nel trasporlo correttamente.

In genere questo avviene quando si cerca di semplificare per non rivolgersi solo a un pubblico settoriale: a volte ci si riesce, a volte no. Qui non ci sono riuscito completamente e quindi ti ringrazio per il contributo. Ho modificato il testo di conseguenza, cercando cmq di mantenerlo alla portata di tutti. Grazie ancora!

[Pino90]

Originariamente inviato da Manolo De Agostini

Ciao, grazie del contributo prezioso. Ahimè tutte le fonti consultate (più di una, non ne prendo mai una, salvo quando è una per forza) - anche autorevoli o di settore Linux - hanno semplificato o non riportato i passaggi del processo di revisione, e questo ha comportato un po' di confusione nel trasporlo correttamente.

In genere questo avviene quando si cerca di semplificare per non rivolgersi solo a un pubblico settoriale: a volte ci si riesce, a volte no. Qui non ci sono riuscito completamente e quindi ti ringrazio per il contributo. Ho modificato il testo di conseguenza, cercando cmq di mantenerlo alla portata di tutti. Grazie ancora!

Figurati, c'è stata la stessa confusione su più o meno tutte le testate. Per esempio il giornalista di Ars Technica ha dovuto chiarire il tutto nei commenti (pagine due e tre).
Mi fa piacere di aver aiutato.