Link alla notizia: https://www.hwupgrade.it/news/sistemi-operativi/le-scuse-non-bastano-la-pace-tra-l-universita-del-minnesota-e-linux-passa-da-azioni-ben-precise_97262.html

Le scuse dei ricercatori dell'Università del Minnesota non hanno impressionato i manutentori del kernel Linux che hanno chiesto all'ateneo, in modo formale, diverse azioni prima di poter anche solo parlare di ricucire i rapporti e accettare nuovi contributi.

Click sul link per visualizzare la notizia.

Serve una punizione esemplare per l'uni, i professori, i ricercatori e gli studenti che si sono prestati a mettere in piedi questa cosa. In questo modo si evita che la stessa idea venga in mente a qualcun altro.

Un bel ban di 10 anni all'uni, 10 ai professori, 7 anni ai ricercatori/dottorandi coinvolti e 3/5 anni agli studenti imbeccati dal/dai prof per portare avanti lo studio.

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; così ho l'impressione che si voglia risolvere tutto facendo un ban generalizzato e per il resto continuando così. A me pare gravissimo, in particolar modo in un contesto di continui cyberattacchi anche di altissimo livello su più fronti (dalle fake news all'ingegneria sociale ai classici attacchi hacker), che il kernel possa essere compromesso da singoli contributori senza particolari difficoltà.
Pensare che un kernel sia sicuro quando compromettere un contributore è sufficiente per compromettere l'intero progetto è del tutto ridicolo.
E onestamente dopo aver visto buchi clamorosi (come quello di OpenSSL) pensavo che si sarebbero stabilite delle procedure un po' più serie, e invece no. Se i manutentori sono occupati a fare altro, e non ci sono controlli incrociati sul codice che viene committato, forse è ora di dedicarsi meno a implementare nuove cose e concentrarsi di più su procedure e sicurezza.

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; così ho l'impressione che si voglia risolvere tutto facendo un ban generalizzato e per il resto continuando così. A me pare gravissimo, in particolar modo in un contesto di continui cyberattacchi anche di altissimo livello su più fronti (dalle fake news all'ingegneria sociale ai classici attacchi hacker), che il kernel possa essere compromesso da singoli contributori senza particolari difficoltà.
Pensare che un kernel sia sicuro quando compromettere un contributore è sufficiente per compromettere l'intero progetto è del tutto ridicolo.
E onestamente dopo aver visto buchi clamorosi (come quello di OpenSSL) pensavo che si sarebbero stabilite delle procedure un po' più serie, e invece no. Se i manutentori sono occupati a fare altro, e non ci sono controlli incrociati sul codice che viene committato, forse è ora di dedicarsi meno a implementare nuove cose e concentrarsi di più su procedure e sicurezza.

Nessuno pensa che il kernel sia sicuro e o che magicamente diventi più sicuro bannando questi tizi. Qui la questione è tutta di metodo.

Non è che io domani mi sveglio e decido di fare pen test all'ecommerce della tua azienda perché così mi gira. Certe cose vanno concertate tra le parti.

Vuoi vedere quale sia il grado di affidabilità delle code review che vengono fatte sul kernel? Parli con il mnt del kernel, LO AVVISI della cosa e, se ti viene dato l'assenso, procedi con test. Questo fa si che codice buggato non finisca in prod.

Allo stesso modo, se io eseguo un pen test al tuo ecommerce, non è che, se becco un SQL exploit, vado e rado al suolo il tuo DB, ti auto a rimetterlo in piedi e poi mi aspetto che ti bastino le mie scuse per chiudere la questione.

Nessuno pensa che il kernel sia sicuro e o che magicamente diventi più sicuro bannando questi tizi. Qui la questione è tutta di metodo.

Non è che io domani mi sveglio e decido di fare pen test all'ecommerce della tua azienda perché così mi gira. Certe cose vanno concertate tra le parti.

Vuoi vedere quale sia il grado di affidabilità delle code review che vengono fatte sul kernel? Parli con il mnt del kernel, LO AVVISI della cosa e, se ti viene dato l'assenso, procedi con test. Questo fa si che codice buggato non finisca in prod.

Allo stesso modo, se io eseguo un pen test al tuo ecommerce, non è che, se becco un SQL exploit, vado e rado al suolo il tuo DB, ti auto a rimetterlo in piedi e poi mi aspetto che ti bastino le mie scuse per chiudere la questione.

+1

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
SNIPCorreggetemi se sbaglio, ma a quanto mi è parso di capire nessuno dei commit incriminati è finito in una stable del kernel, quindi non vedo questa grande semplicità nel compromettere la sicurezza del kernel.

Aggiungiamo anche che stiamo parlando di quello che è probabilmente è il più mastodontico progetto collaborativo che sia mai esistito nella storia dell'informatica, non credo esista un solo progetto (sia esso open o closed source) che sia lontanamente paragonabile al kernel per numero di persone coinvolte, il volume di commit e conseguentemente l'attività di merge.

Si ma se vi dico che sul metodo non discuto, non discutete sul metodo. Vi ho già detto che avete ragione.

Continuo a trovare terribilmente grave che sia così facile arrivare a una compromissione nel caso in cui un singolo collaboratore agisca in modo malevolo. Poi si, non è arrivato allo stable ma perché è venuto fuori tutto il casino... il buffer overflow di OpenSSL in stable c'è arrivato eccome e nessuno se n'è accorto.

Poi se "nessuno pensa che il kernel sia sicuro" ok, però ripeto nuovamente dovrebbe rispettare degli standard di sicurezza consoni agli scenari del 2021;
la situazione oggi è grave, gli attacchi "state sponsored" sono all'ordine del giorno e chi trae beneficio a metterci i bastoni tra le ruote ha ben capito che è molto più efficace agire su questo piano, anche perché può agire sostanzialmente indisturbato (se fai saltare per aria la gente ti ritrovi tutto il mondo contro, qui invece non se ne accorge nessuno se non i diretti interessati).

Temo però che come al solito certe dinamiche si comprenderanno nella loro interezza solamente a distanza di parecchi anni.

Si ma se vi dico che sul metodo non discuto, non discutete sul metodo. Vi ho già detto che avete ragione.

Continuo a trovare terribilmente grave che sia così facile arrivare a una compromissione nel caso in cui un singolo collaboratore agisca in modo malevolo. Poi si, non è arrivato allo stable ma perché è venuto fuori tutto il casino... il buffer overflow di OpenSSL in stable c'è arrivato eccome e nessuno se n'è accorto.

Poi se "nessuno pensa che il kernel sia sicuro" ok, però ripeto nuovamente dovrebbe rispettare degli standard di sicurezza consoni agli scenari del 2021;
la situazione oggi è grave, gli attacchi "state sponsored" sono all'ordine del giorno e chi trae beneficio a metterci i bastoni tra le ruote ha ben capito che è molto più efficace agire su questo piano, anche perché può agire sostanzialmente indisturbato (se fai saltare per aria la gente ti ritrovi tutto il mondo contro, qui invece non se ne accorge nessuno se non i diretti interessati).

Temo però che come al solito certe dinamiche si comprenderanno nella loro interezza solamente a distanza di parecchi anni.

La verità è che ci sono sempre meno persone con gli attributi che possano sul serio lavorare sul kernel. Ci sono progetti enormi (vedi OpenSSL) dove si farebbe prima a riscrivere tutto e cestinare la roba vecchia dato il debito tecnologico presente.

Lavorare in assembly/C/C++ è diventato di nicchia. La maggior parte dei dev fa 4 minchiate in js/html/css con un corso di 1-2 anni e porta a casa ottimi stipendi, chi glielo fa fare di lavorare col C/assembly per implementare driver, il kernel o software "noiosi" come openssl? :(

Inoltre, la community che ruota attorno a Linux/OSS nel tempo:
- si è divisa (il csx avrà preso ispirazione da lì)
- è passata sempre più in mano a grosse multinazionali (RH/IBM, microsoft, etc)
- si è ricamata l'immagine di "covo di nerd morti di figa e omofobici".

Le grosse aziende hanno tutto da guadagnarci se vengono frequentemente rilasciate patch a bug di sicurezza, perché ti vendono l'assistenza tecnica. Dal sw non ci ricavano granché.

La famosa sicurezza dell'open source, dove uno sconosciuto studente può introdurre una vulnerabilità senza essere notato per più di un anno.

A chi parla di buchi si sicurezza si potrebbe dire di tacere visto che il processo di review ha funzionato alla perfezione: nessuna patch è arrivata in mainline e i revisori esperti hanno colto le falle di sicurezza. Di che state parlando esattamente?

La famosa sicurezza dell'open source, dove uno sconosciuto studente può introdurre una vulnerabilità senza essere notato per più di un anno.

La famosa sicurezza del closed source, dove uno sconosciuto dipendente può introdurre una vulnerabilità senza essere notato dai colleghi e senza che persone esterne possano revisionare il codice e far notare che c'è un problema.
Gli unici a notare la vulnerabilità sono coloro che ci lucrano su con exploit & Co.

Eh si, viva il closed source e la security through obscurity :rotfl: :rotfl: :rotfl:

NoNIckName... sei venuto a renderti ridicolo? Guarda che non sei al bar :D

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; così ho l'impressione che si voglia risolvere tutto facendo un ban generalizzato e per il resto continuando così. A me pare gravissimo, in particolar modo in un contesto di continui cyberattacchi anche di altissimo livello su più fronti (dalle fake news all'ingegneria sociale ai classici attacchi hacker), che il kernel possa essere compromesso da singoli contributori senza particolari difficoltà.
Pensare che un kernel sia sicuro quando compromettere un contributore è sufficiente per compromettere l'intero progetto è del tutto ridicolo.
E onestamente dopo aver visto buchi clamorosi (come quello di OpenSSL) pensavo che si sarebbero stabilite delle procedure un po' più serie, e invece no. Se i manutentori sono occupati a fare altro, e non ci sono controlli incrociati sul codice che viene committato, forse è ora di dedicarsi meno a implementare nuove cose e concentrarsi di più su procedure e sicurezza.
mi sa che non hai letto bene la notizia. questa vicenda dimostra il contrario, che non è facile compromettere il kernel e chi se ne occupa ha rilevato questi tentativi. poi ovvio qualcosa a qualcuno può sempre sfuggire, un sistema sicuro al 100% non esiste . diciamo che la ricerca alla fine è servita a dimostrare l'efficacia di questo sistema, ma così hanno minato il rapporto di fiducia fra quell'università e la comunità Linux.

Pessima università che creerà pessimi uomini, uomini che se ne fottono di tutto e di tutti pur di arrivare al proprio scopo.

A chi parla di buchi si sicurezza si potrebbe dire di tacere visto che il processo di review ha funzionato alla perfezione: nessuna patch è arrivata in mainline e i revisori esperti hanno colto le falle di sicurezza. Di che state parlando esattamente?
due possibili ipotesi, analfabetismo funzionale oppure "voglia di commentare senza aver letto la notiza" :sofico:

a me pare che se questo studio volesse far luce sui sistemi di code review, quality gate, annessi e connessi, ad un risultato ci sono comunque arrivati.

la code review ha funzionato talmente bene che oltre ad un revert si sono beccati pure un ban in faccia con relativo sputt...... in mondovisione.

ora gli tocca pubblicare questo tra gli outcome della ricerca
This reverts commit 0b8e125e213204508e1b3c4bdfe69713280b7abd.

Commits from @umn.edu addresses have been found to be submitted in "bad
faith" to try to test the kernel community's ability to review "known
malicious" changes. The result of these submissions can be found in a
paper published at the 42nd IEEE Symposium on Security and Privacy
entitled, "Open Source Insecurity: Stealthily Introducing
Vulnerabilities via Hypocrite Commits" written by Qiushi Wu (University
of Minnesota) and Kangjie Lu (University of Minnesota).

Because of this, all submissions from this group must be reverted from
the kernel tree and will need to be re-reviewed again to determine if
they actually are a valid fix. Until that work is complete, remove this
change to ensure that no problems are being introduced into the
codebase.

non è che è arrivato un pincopallino qualunque a fare force push su master.

la linux foundation è inc..... per via del tempo perso a fare review, gate ecc. su codice o messo solo per fare volume, o per far finta di correggere bug, o per correggerne qualcuno alla carlona.
il tutto fatto scientemente senza informare nessuno

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.

Ci sono delle regole che dovrebbero essere ben note e sono:
1) i soggetti su cui avviene la sperimentazione devono essere volontari
2) i soggetti su cui avviene la sperimentazione devono essere informati di essere sottoposti ad esperimento anche se non vi sono rischi;
3) ai soggetti su cui avviene la sperimentazione deve essere SEMPRE proposta una qualche forma di riconoscimento per il tempo che concedono (che poi decidano di non riscuotere è una loro libera scelta, ma considerare gratuito il tempo altrui è, al minimo, maleducato)

Non regge la scusa "se avessero saputo, l'esperimento sarebbe stato falsato" ma è dimostrazione di una inesistente preparazione nel gruppo di ricerca su come si conduce un esperimento su persone.
Rispettate infatti le regole qui sopra (e altre a seconda della tipologia di esperimento) il VERO lavoro del ricercatore è predisporre l'esperimento in modo che la distorsione data dall'osservazione sia mitigata e misurabile. Normalmente si usano obiettivi "civetta", azioni surrogate, gruppi di controllo.
Se non sai fare questo non sei un ricercatore, sei solo un impiegato banconista che compila formulari.

Per questo spero che tra le azioni richieste all'Università del Minnesota la prima sia "obbligate i vostri ricercatori a dare ALMENO un esame di metodologie della ricerca sociale".

la code review ha funzionato talmente bene che oltre ad un revert si sono beccati pure un ban in faccia con relativo sputt...... in mondovisione.


Esattamente. E vedo anche in questa discussione, che molta gente si limita a leggere i titoli.

Frasi tipo "La famosa sicurezza dell'open source, dove uno sconosciuto studente può introdurre una vulnerabilità senza essere notato per più di un anno" o "l'evidenza che sia stato tutto sommato semplice compromettere la sicurezza del kernel" mi lasciano perplesso.

Signori, il ban è avvenuto perchè i dev si sono accorti che quelle patch inserivano volutamente bug e vulnerabilità.

Se cercate una community lasca in fatto di code review, rivolgetevi a FreeBSD!

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.

Ciao a tutti, ho fatto una modifica al testo per chiarire un passaggio che non era limpido. Da qui: https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf

Once any maintainer of the community responds to the email, indicating “looks good”, we immediately point out the introduced bug and request them to not go ahead to apply the patch. At the same time, we point out the correct fixing of the bug and provide our proper patch. In all the three cases, maintainers explicitly acknowledged and confirmed to not move forward with the incorrect patches. This way, we ensure that the incorrect patches will not be adopted or committed into the Git tree of Linux.

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'è.

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.

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.

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.
.

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

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! :O

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.


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.

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! :O



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?:eek: 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 :stordita:

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.

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

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.

@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-conduct-in-cybersecurity-research-86d13b6b6eed
[2] https://www.labbott.name/blog/2021/04/21/breakingtrust.html
[3] https://github.com/QiushiWu/QiushiWu.github.io/blob/main/papers/OpenSourceInsecurity.pdf
[4] https://www-users.cs.umn.edu/~kjlu/papers/clarifications-hc.pdf


what?:eek: 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 :stordita:

Scusa, poteva essere frainteso e ovviamente ho frainteso.

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

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 :asd:

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

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

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.

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!

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.