Greg Kroah-Hartman reagált a Minnesota Egyetem diákjainak bocsánatkérésére

Címkék

Mint az ismert, a Minnesota Egyetem egyik kutatói csoportjának néhány tagja kernel bugokat hozott létre és küldött be a Linux kernelhez. Azt állították, hogy céljuk a Linux kernel patchelési folyamatában levő problémák feltárása és azok javítása volt. A kernelfejlesztői közösség nem fogadta kitörő örömmel a kezdeményezést. Reakcióként kilátásba helyezték 190 darab, Minnesota Egyetemhez köthető patch revert-elését a mainline kernelben.

A kutatói csoport három tagja, Kangjie Lu, Qiushi Wu és Aditya Pakki szombaton egy bocsánatkérő nyílt levelet küldött az LKML-re. Greg Kroah-Hartman reagált a bocsánatkérésre:

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,

greg k-h

Levelében megemlítette, hogy a Linux Foundation és annak technikai tanácsadó testülete pénteken levelet küldött az üggyel kapcsolatban az egyetemnek, amelyben kifejtették, hogy milyen lépéseket kell az egyetemnek és a kutatói csoportnak foganatosítania ahhoz, hogy visszaszerezhessék a kernelfejlesztői közösség bizalmát. Amíg ezek a lépések nem történnek meg, addig nincs miről beszélni ezzel az üggyel kapcsolatban.

Hozzászólások

Maradjon az egyetem és a kutatók permabanja. Kicseszés, de ez egy bizalmi dolog. Hogyan lehet egy olyan intézményben még egyszer megbízni, amelyik egyszer eljátszotta ezt? Idővel, mi lenne a következő? Backdoor beküldése patchben, hátha átmegy?

"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Egyfelől egyetértek.
Másfelől nem tudom, mennyi ebben az egyetemnek, mint intézménynek a felelőssége. Nem valószínű, hogy volt rektori hozzájárulása a mongoloidoknak, és szerintem a sztori is minimum necces. Én fegyelmi vizsgálatot rendelnék el az egyetem vezetősége helyében.
A permaban kiszúrás az egyetem többi hallgatójával, akiknek ehhez a bagázshoz közük sincs.

De most komolyan, ha az egyetemi email címmel nem tud beküldeni valaki változást, mennyi problémát okoz egy új email cím regisztrálása, mondjuk gmail-en vagy akárhol?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

(Kb annyiban van értelme, hogy esetleg egy maintainer úgy gondolhatja, hogy egy tekintélyes egyetem emailcíméről jött kód talán megbízhatóbb, mint a randombela@cicamail.hu-ról származó. No meg lélektanilag, hogy ezzel a kollektív büntetéssel is motíválják az egyetemet, hogy foglalkozzon az üggyel.)

A grsecurity alapítója Greg Kroah-Hartman eltávolítását kéri a Linux Kernel Code of Conduct Committee-ből:

Hi,

I'd like to ask for the removal of Greg KH from the Code of Conduct Committee
and to be replaced with another kernel developer who comports his/herself in
a way that aligns with the Linux Kernel Code of Conduct.

This was originally going to be a code of conduct report against Greg KH
until I saw that he was on the board that would handle it.  That I
considered not even bothering to submit the report regarding his egregious
actions demonstrates that he should not be on the committee.

Levele itt

trey @ gépház

Ez csak egy sértődött rosszindulatú puffogás. Az ég világon semmit nem bizonyít. A hülye kutatók, ha nem rosszhiszeműen jártak el, akkor igencsak rossz módot választottak a kísérletükre. Ekkora balfácán kevés van a világon, ráadásul még csak nem is etikusan jártak el - aki tátott szájjal rohangál a f*szerdőben, az így jár. A grsecurity-s csávó semmivel sem korrektebb, mint gkh és a linuxos csávók.

szerintem spender csak trollkodik, nincs kifejezetten jóban a kernel fejlesztőkkel. Egyrészt voltak nekik kétes húzásaik gpl ügyben az üzleti modelljükkel, másrészt azon is volt némi bili borogatás, hogy valami segg beküldte beolvasztásra a grsecet, amit ők egyébként egyáltalán nem akartak, utána/ezzel együtt meg azon ment valami vekergőzés, hogy a fene tudja ki a  mainlineban elkezdte újraimplementálni a featureök egy résztét csak a gresces srácok szerint szarul, mert nem érti mit másol...

outlining the specific actions which need to happen in order for your group

Engem mondjuk ez érdekelne, de ez úgy látom, nem a threadben van.

Nem hinnem.

Egyik korabbi levelben pl. olyat kertek, hogy tetelesen listazzak, hogy milyen patcheket kuldtek be eddig, es jeloljek meg, hogy melyik valid, es melyik “hypocrite commits” (jelentsen barmit is). Ilyet meg nem lattam toluk. Mindig csak azt irjak, hogy ez sem az, az sem az.

Ez a “hypocrite commits” is zavaros szamomra. Azt irjak, hogy nem rosszindulato kod, de nem is valos hibat javito. Akkor kozmetikai fix vagy mi?

Ha ezer jó patch mellé egy backdoort küldök, akkor jó vagyok?

:)

Ha jól értettem, arról volt szó, hogy nem akarják rendesen átnézni, ki mit küld valójában a kernelbe, hanem bizalmi alapon lövik be az ellenőrzés mértékét. Ha jól értettem, egyes HUP-osok szerint a mostani eset kapcsán szopás újracsekkolni a patcheket. Mekkora fejvakarás lesz, ha egy bizalmat nyert hozzájáruló öt éve beküldött patchében találnak gonoszságot?

A kernel elvileg egy tervezett, mérnöki alkotás. Mi köze a bizalomnak a mérnöki munkához?

:)

Code review-n ha tudod, hogy a bekuldo kezdo, jobban atnezed, illetve konnyebben belekotsz formai dolgokba. Ha X eve ismered, atment teszteken, es tudod, hogy az illeto jo munkat vegez, akkor nem biztos (kiveve, ha mondjuk kulon keri, vagy uj neki az adott terulet). Illetve ha egy megbizhato embered mar egyszer rabolintott egy mashonnan jovo patchre (Linus gondolom nem nez mar at mindent, keptelenseg lenne), akkor oke. Szoval attol, hogy mernoki alkotas, meg szamit az - alapvetoen kompetenciaval elnyert - bizalom.

A strange game. The only winning move is not to play. How about a nice game of chess?

Jobb helyeken elmagyarazzak, hogy milyen normakat is illene betartani a kutatoknak pontosan az ilyen esetek elkerulese erdekeben. Ugy tunik, itt nem nagyon sikerult.

Mondjuk, ez annak idejen a BME-n se kerult elo sajnos...

Szerintem, meg az elmúlt 20 évben beküldött patchek 2/3-a nem volt komolyabban (logikai végigkövetéssel) átnézve, csak úgy ímmel-ámmal, hogy ne okozzon crash-t.

A másik sanda gyanúm, hogy, úgy a 5-10%-a direktben beküldött sérülékenység, ami nincs észrevéve, csak ez most kibukott, mert egy egyetem csinálta, de az igazán komoly backdoorokat nem egyetemi kutatók küldik be.

Ezt sem vették volna igazán észre, ha nem kerül ki az egyetemen készült tanulmány a kutatás eredményeiről.

 

Itt ismét a monolitikus felépítés a probléma forrása, mert annak kötelező következménye a "manyeyeball" szemlélet, de, mint azt a jó magyar közmondás már évszázadok óta ismeri: Közös lónak túrós a háta.

De azon sem lennék meglepődve, hogyha az egész, egy, a linux kulcsembereinek tudta nélkül, megtervezett színjáték/kísérlet, a kernel "close-source" irányába történő eltolására, avagy a szabadon közreműködés lehetőségének elvételére. (Következtetek erre az egyetem himi-hümi válaszreakcióiból.)

A túr az egyfajta habos verejték a ló testén, főleg a hátán.
A Túr folyóval talán rokon.

Azért túros a háta a közös lónak, mert minden tulaj csak addig érzi magáénak az állatot, amíg az hasznot hajt. Ha már foglalkozni is kell vele (lemosni), azt tegye inkább más.

Nem feltétlenül sejtek összeesküvést.
Talán csak túl nagy lett a kernel és az egész ecosystem (és a betöltött szerepe miatt relevánsabb célpont lett), hogy az eddig megszokott módon működjön tovább a felügyelete.

Még mindig sokkal jobb a képlet, mint a windows esetében. És ez a probléma is meg fog oldódni.

Lehet, hogy így van.

Engem csak a történet elfajulása zavar.

A BLM-ről se gondolta senki tavaly májusban, hogy hova fut majd ki.

V.Ö.: https://hup.hu/comment/2622711#comment-2622711

 

Amúgy meg a világ mindig a lustaság irányába mozdul el, így volt ez az Androiddal, amikor a Linux kernelt választotta, mert egyszerűbb volt azt kibővíteni, pedig Linus hevesen érvelt az "ARM baromságok" támogatása ellen.

És így lesz ez az IoT világában is majd, amitől meg csak még nagyobb lesz a hangzavar.

És így lesz ez az IoT világában is majd, amitől meg csak még nagyobb lesz a hangzavar.

Persze, mert kb. ez maradt az egyetlen well-maintained és supported szabadon használható kernel, amihez megvannak a cullangok is. Lesznek a Linuxos eszközök, meg a proprietary fos eszközök. Esetleg beszáll majd az ms, elér három év alatt másfél százalékos penetrációt, aztán kiszáll. ;->

Amikor az Android jött már sok éve volt ARM támogatás a kernelben, szóval nem tudom milyen baromságokra utalsz.

Az Androidnak volt néhány arch független módosítása (pl. Binder, ashmem ... stb.), amik persze először kiverték a biztosítékot, de mára elvileg egy modern mainline kernel tud Androidot bootolni.

Szerkesztve: 2021. 04. 27., k – 14:39

Ha tényleg kutatás volt, akkor hol az etikai engedély? Vagy ilyesmire nem kell?

Vagy kutatási terv? Hogyan monitorozta a bug beépülését a kernelbe? ráláthatott?

Ja, egyszer hozzánk jelentkezett egy indiai fószer, aki a CV-jében azt írta, hogy ő regular glibc contributor. Találtam a nevén 1db rejectelt patchet, nyolc évvel korábbról. Mikor a szóbeli interjún rákérdeztük, akkor hebegett-habogott, majd közölte h. hát a legtöbb patchet a munkahelye nem engedte(!) upstreamelni ezért ő a belső verziót tartotta karban. Amikor rákérdeztem hogy ez nem GPL violation-e, akkor mondta, hogy ő nem egy ügyvéd. Mi se, de azért nem vettük fel. :P

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

lol

Én emlékszem, hogy az (infós) évfolyamunkon az egyetlen félévnyi jog kurzus hogy kiverte mindenkinél a biztosítékot. MiNeK kElL jOgOt TaNuLnI? Ezért, b+. :)

És nyilván nem elméleti jogtudomány volt az anyag, hanem konkrét esetek szerzői jogban, stb. Nekem a megajánlott ötösöm abból lett, hogy bemutattam az Apple vs Samsung aktuális ügyet. Szerintem baromi fontos egy informatikusnak, hogy legalább egy ilyen összefoglalót tudjon parse-olni.

Ez jól hangzik. Nálunk infón szintén volt fél év jog, szintén hasznos volt (szerintem), de teljesen más volt a téma: vállalkozási formák, vállalkozás alapítás, szerződések, tartozások, felszámolás, ilyesmi.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Hát csak emiatt tényleg felesleges lenne. :)

Btw ha nem a képzési hely pedigréje a legfontosabb, akkor ~2 millából megvan saját zsebből, normális oktatókkal, teljesen barátságos időbeosztással, stb. mondjuk egy ELTE-n. Heavily recommended, ha érdekel az ilyesmi.

Ha számít, hogy külföldön is ismertebb helyről legyen a papír, akkor ösztöndíjakkal ki lehet bulizni 15000 euró körül, ez még éppenséggel munkáltatónál is lehet a lélektani határokon belül. Nyilván az ilyen INSEAD-féle ~125000 eurós képzésekre menjen, akinek hét anyja van, vagy öttalálatos lottószelvénye.

Najó, de akkor az nem regular glibc contribution. :) Nekünk is vannak belső patcheink, pl. Buildroothoz, a Linux kernelhez meg az UBoothoz, olyan is amit tök semmi értelme upstreamelni, pedig a cég engedné, de én nem is írom a CV-mbe hogy regular Buildroot meg Linux kernel contributor. :)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Amikor rákérdeztem hogy ez nem GPL violation-e

Miért lenne az?

Forkolni szabad. A saját forkod változásait nem muszáj az eredeti verzió számára visszaküldeni.

Ha csak cégen belül használják, akkor még a forrást se kell kiadniuk senkinek. Ha ügyfélnek szállítják a saját glibc verziójukat binárisan, akkor az ügyfél kérésre az ügyfél rendelkezésére kell bocsátani a forrást. Ennyi.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nyilván. De nem is erre próbáltam utalni. Hanem hogy a csávó más tollával akart ékeskedni, és közben fingja sem volt semmiről. (Amúgy a CV-ben emellett ismert cég ismert terméke is volt, így jogos volt az upstreamelési igény, vagy mint ötlet. Mondjuk válaszként min. elvártam volna, hogy ezt amit leírtál elmondja. De még attól sem lesz mindez regular glibc contribution...)

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-

Amúgy se vettük volna fel, sok szempontból, bár a tesztfeladat megoldása nem volt teljes kudarc (írj egy embedded ringbuffer implementációt C-ben, plusz teszteseteket hozzá, és ott még azt is elfogadtuk ha valaki sikeresen kiválaszott egyet a jobb "guglin találtam" implementációk közül és _értelmes_ teszteket írt hozzá), emiatt eljutott a szóbeli körbe, de ott simán kihullott.

-=- Mire a programozó: "Na és szerintetek ki csinálta a káoszt?" -=-