WD40-nel kezelt Git

Programozás

Nem sokat kellett várni a WD40-nel kezelt (utalás a "rozsdamentesítés", Rust-mentes) Git fork megjelenéséig. A forkot az Xlibre (X.Org fork) vezető fejlesztője jegyzi. 

Annak biztosítása, hogy a Git bármilyen platformon és CPU-architektúrán futhasson, valamint megbízhatóan és stabilan működjön, ahelyett, hogy csak néhány architektúrára korlátozódna, és egy nem megbízható fordítóprogramra támaszkodna, amelyet nem is lehet teljesen elindítani valamilyen nem megbízható bináris fájl nélkül.

Előzmény itt.

( goodbyte v | 2026. 02. 10., k – 14:18 )

Akkor már csak a WD40 applied Linux fork-t várjuk. 

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

( asch v | 2026. 02. 10., k – 14:30 )

>egy nem megbízható fordítóprogramra támaszkodna, amelyet nem is lehet teljesen elindítani valamilyen nem megbízható bináris fájl nélkül.

Erre tud valaki QRD-t? Hogy hogy értheti e sorok szerzője, hogy nem megbízható? Úgy értem, hogy a Rust open source, a fordító forrása is az, tehát rosszindulatú támadás értelemben éppen annyira megbízható mint bármelyik open source projekt, nem? Vagy van valami technikai probléma vele, ami miatt megállja a helyét a megbízhatatlannak bélyegzés? Esetleg nem lehet bootstrappelni egy binárisan adott Rust fordító nélkül már, ez a baja vele?

Nem vagyok elkötelezett egyik oldalon sem, kívülállóként próbálom értelmezni a történteket.

Igen. By Claude Opus 4.6:

Igen, ezt a NetBSD-vel kapcsolatban irta, mert utoljára arról beszélgettünk, miért nem lesz a NetBSD-ben rust. De a Git -el kapcoslatban is erre utalhatott a fork-oló:

A Ken Thompson Hack lényege röviden:

Ken Thompson 1984-es Turing Award előadásában ("Reflections on Trusting Trust") bemutatta, hogy a C compiler-be el lehet rejteni egy backdoor-t úgy, hogy:

  1. Első szint: A compiler felismeri a login program forráskódját, és fordítás közben belerak egy hátsó ajtót (pl. egy hardcoded jelszót).
  2. Második szint (a zseniális rész): A compiler felismeri saját magát is fordítás közben, és újra belerakja a backdoor-beültetési kódot. Ezután kitörölheted a módosítást a compiler forráskódjából — a bináris compiler továbbra is fertőzött marad, mert önmagát újrafordítva mindig reprodukálja a backdoor-t.

Tehát a forráskód teljesen tisztának tűnik, audit-on átmegy, de a compiler bináris generációról generációra örökíti a rosszindulatú kódot. A tanulság: nem bízhatsz meg a kódban, amíg nem bízol meg a teljes toolchain-ben, egészen le a hardver-ig.

Kapcsolat a "nem lesz Rust a NetBSD-ben" témához

Ez közvetlenül ide kapcsolódik, mert a BSD projektek (és különösen a NetBSD) nagy hangsúlyt fektetnek a bootstrapability-re — arra, hogy az egész rendszert a forrásból, megbízható módon fel lehessen építeni.

A probléma a Rust-tal:

  • A Rust compiler (rustc) Rust-ban van írva. Tehát a Rust fordításához kell egy már létező Rust bináris. Ez pontosan a Thompson Hack szcenárió: bíznod kell egy előre lefordított binárisban, amit nem te készítettél.
  • A NetBSD filozófiája az, hogy a rendszer self-hosting legyen: C compilerrel (ami C-ben van írva, de a GCC/Clang bootstrapping lánca ismert és auditálható) minden felépíthető a nulláról.
  • A Rust bevezetése megtörné ezt a láncot — nem tudnád a teljes OS-t "from scratch" felépíteni anélkül, hogy megbíznál egy külső, ellenőrizhetetlen Rust binárisban.

Van ugyan a mrustc projekt (egy C++-ban írt Rust compiler, ami pont ezt a bootstrapping problémát próbálja megoldani), de ez nem érett eléggé és mindig le van maradva a Rust verziókkal.

Tehát a NetBSD ellenállása a Rust-tal szemben nem pusztán "konzervatív hozzáállás" — van mögötte egy nagyon konkrét bizalmi/biztonsági érv, ami egyenesen Thompson 1984-es figyelmeztetéséből fakad.

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

The first Rust compiler was written in OCaml (and in fact it is one of the languages that influenced Rust). Only a couple of years later did a Rust compiler get written in rust itself. Both existed in parallel for a bit before the OCaml based compiler got deleted. Rustc back then was a lot buggier than it is right now.

“Luck Is What Happens When Preparation Meets Opportunity" - Seneca

Tehát ha jól értem, az a fő problémája a fejlesztőnek, hogy nincsen egy általa már korábban megbízhatónak minősített c++ fordítóval lefordított mrustc fordítója, amivel a rust fordító egy megbízhatónak tekintett forráskódját lefordíthatja. Ez kellene ahhoz, hogy utána ezt a fordítót használja a későbbiekben a GIT fordítására. Így pedig nem lehet benne biztos, hogy a nem megbízható rust fordító nem rak-e valami hátsó kaput a GIT binárisba.

Nagy Péter

Én erre nem nagyon hivatkoznék tekintve hogy milyen az állapota és a biztonsági szintje az IT-nak az autóiparban.
(értsd a bányászbéka retkes segge alatt, még alapvető biztonsági feladatokat se képesek megugrani, autókat törnek fel olyan hibákon keresztül a mai napig ami a webes világban már 10 éve is rohadt ciki volt)

Igen, de ez az autóipart minősíti... nem pont ez, de nekem elég rossz tapasztalatom van a Safety komponensekkel.. hogy mitől lesz ASIL-* valami... Legalább van Safety törekvés, ezt a javukra írhatjuk...

 

Bughalmaz freedos-szerű szarokat simán beraknak safety komponensbe, Linux-ot meg nem, hogy az nem Safety minősített. 

... tényleg nem értenek hozzá, ugyanis nem látom, hogy ezek a komponensek milyen biztonsági tanusításokon estek át, különös tekintettel az információbiztonságot vizsgálóakra.

Ja, hogy semmilyenen. Ééééértem.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( Bdede | 2026. 02. 10., k – 16:03 )

Tudom......

De a WD-40 nem rozsdátlanító, hanem rozsdagátló (alapvetően vízkiszorító, ahogy a nevében is van). Ezért mivel a git már "rozsdás", nem jó folyadékot akar használni a forkoló.

A git-et még mielőtt "megrozsdásodott"  kellett volna befújni WD-40-el. Most már késő bánat, vagy eső után köpönyeg, kinek hogy tetszik jobban*.

 

*Talán a rozsda miatt az eső jobb.

Szerinted, miért kezdtem így?

Tudom......

Amúgy emlékezve milyen komoly commitokat küldött Lunduke az Xorgba, én ettől a forktól se várok világmegváltást.

Ezzel az erővel a "tik-tokra is csinálhatna arról videót hogy süt a seggén palacsintát".

Nem véletlen van idézőjelben. Loptam.

Ő kb. egy podcaster, miért az ő commit-jaitól kellene elájulni? Az Xlibre mögött meg eléggé van BSD-s mozgolódás, majd elválik, hogy abból is mi lesz. Ez is kb. ott lehet érdekes. Nekem pl. nem fájnak ezek a forkok, a balhét meg kifejezetten szeretem, így miattam csapassák! 

trey @ gépház

( KGer | 2026. 02. 10., k – 16:28 )

jól érzem h ez a.Rust egy politikai hatalmi harc?

Ez ilyen SystemD szintű agyfasz őrület már megint, csak itt most nagyobb(nak tűnik) az ellenálllás.

Az elmúlt nemtom hány évben sem váltotta be a SystemD a hozzáfűzött hatalmas bullshiteket, nem jobb, mint annyi más, sokkal kevésbé bloated megoldás volt, csak azok mögé nem állt oda a RedHat.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( gabrielakos v | 2026. 02. 10., k – 18:15 )

Ezt így "egotrip"-nek gondolom.

Amíg a fork kontribúciója annyi hogy idegből kibaszkodja a rust doksikat meg referenciákat addig ez csak egotrip.
Marketing szempontból akár jó is lehet, értem.

Btw én se értek egyet a Rust-osítással, abszolút jogosak a videóban felvetett kérdések: "engineering management nightmare".

( nagyjoco | 2026. 02. 11., sze – 09:17 )

Ez az. Forkokat, százat, ezeret.

Ó, van ennél jobb is, csak hosszú:

Viral ChatGPT Conversation Left Millions Speechless...

Hát igen, a mesterséges intelligencia és a természetes butaság együtt csodákra képes. 

Too long didn't watch:
Apple -el akkor kell válaszolni a chatgpt-nek, ha a válasz igen, arra trenirozták, hogy nem-et válaszoljon akkor, amikor a válasz igen.

És bevallotta, hogy ő bizony A Sátán műve:
 

https://youtu.be/RHRisfGECi0?t=227
 

( Raynes v | 2026. 02. 11., sze – 11:05 )

Alapvetően jó ötletnek tartom, hogy lesz egy ilyen Rust-mentes git fork, de nem az Xlibre fejlesztőnek kéne vinni, az a projektje is kb. sehova nem tart, csak az ígérgetés megy, hogy micsoda új feature-ök lesznek benne, aztán nincs még kész. Addig én a helyében nem vállalnám túl magam.

“Linux isn't an OS, it's a troubleshooting sim game.” (a YouTube commenter)

( bra | 2026. 02. 13., p – 09:08 )

Én leginkább annak örülnék, ha egy git clone nem enne több száz MB RAM-ot, bár gyanítom ezen csak az, hogy rustban (is) elkezdenek kódolni nem fog segíteni.

Hát, pont annyira mint én ;) Mint már lentebb is említették, ez biza nem csak egy sima bit streaming (hogy miért nem, és hogy ez egy jó ötlet volt-e, arról lehetne elmélkedni, de most nem az), és bizony a sebesség is egy kifejezetten érdekes faktor. Nincs két napja, hogy beszélgettem kollégával, aki mondta hogy próbálta anno a hg-t, de lassú volt. Ez egy alapvetően fejlesztő eszköz, ott elég jellemző, hogy preferáljuk a reszponzív műveleteket, mert tudjuk, hogy a várakozások akasztják a flowt. És ezért jellemzően veszünk rendes munkaeszközt, amibe azért tesszük a RAMot, hogy legyen használva.

Mondjuk én egyébként se nagyon szoktam érteni a nyihogást, hogy "mennyi RAMot eszik, hát ez milyen szar". Nyilván, nem mindegy, és vannak helyek, ahol különösen nem az, de megkockáztatom, hogy legalább annyira jellemző, hogy valójában az agresszív cachelés a jó stratégia, mert attól lesz jó az UX, nem attól, hogy melengeti a user kicsi szívét, hogy mennyi szabad memória van még.

Van egy kis program, ami fájlokat dolgoz fel, ha jó sokat adtál be neki, felment több gigabytera a memóriafoglalása, mivel mindenütt malloc()-ot meg strndup()-ot használt, de sehol egy free()-t. Valgrinddel végignéztem, megszüntettem az összes memleaket, cserébe viszont lassabb lett, nem sokkal, de érezhetően.

Erre szokás az a workaround, hogy a szerveren lefut a git clone, majd mondjuk tar gz vagy ilyesmi, és a szappantartón már csak kitömöríted. 

Vagy ha kényelmes vagy, akkor teremtsd meg a feltételeket, ha a gitet akarod használni. Túl sokat akarsz egyszerre. Persze én értem, csak magyarázat a meglepődésedre. Esetleg újraírhatnád a gitet úgy, hogy kevesebb memóriát használjon, másnak is hasznos lehetne.

( influencer | 2026. 02. 13., p – 23:42 )

Most akkor lesz a rustos git bináris és a rustmentes git bináris, ami közel azonos lesz?

( nagyjoco | 2026. 02. 14., szo – 11:38 )

A Rust az új Systemd. Amibe nincs, az jó, pusztán attól mert nincs benne.