● news.bsdnet.hu

A Canonical korábban azt tűzte ki célul, hogy az Ubuntu 25.10-ben alapértelmezetté teszi a Rustban írtuutils coreutilscsomagot, majd ha a feltételek adottak, ezt az Ubuntu 26.04 LTS-be is továbbviszi. A coreutils olyan alapvető Unix/Linux parancsokat tartalmaz, mint azls,cp,mv,rm,mkdirvagy achmod. A váltás mögötti fő érv a nagyobb biztonság és robusztusság volt, de a történet gyorsan árnyaltabb lett. A Canonical biztonsági felülvizsgálatot és külső auditot kért aZellic-től, amely két körben összesen 113 problémát talált, ezek közül 44 CVE-t kapott. Ennek eredményeként az Ubuntu 26.04 LTS-ben acp,mvésrmtovábbra is a GNU coreutilsból érkezik, mert ezeknél még nyitott TOCTOU, vagyis time-of-check to time-of-use típusú race condition hibák maradtak. A Canonical szerint a cél továbbra is a teljes átállás, várhatóan az Ubuntu 26.10 környékén. Az oss-sec listán Collin Funk, a GNU coreutils egyik commitere arra hívta fel a figyelmet, hogy a Rust-újraírásnál nem a klasszikus memóriabiztonsági hibák jelentik a fő veszélyt, hanem a fájlok létrehozása, törlése és jogosultságállítása körüli versenyhelyzetek. Példaként amkfifo, anohupés atailviselkedését említette, ahol a GNU coreutils évtizedes tapasztalatból már óvatosabban kezel bizonyos eseteket. A tanulság nem az, hogy "a Rust rossz", hanem az, hogy az alapvető rendszereszközök újraírása nem pusztán nyelvi kérdés. A memóriabiztonság fontos előny, de nem helyettesíti a Unix-jogosultságok, szimbolikus linkek, ideiglenes fájlok és race condition minták körül évtizedek alatt összegyűlt tapasztalatot. A témára Michał Zalewski, ismertebb nevén lcamtuf is felhívta a figyelmet az X-en. But do you know what coreutils are a fertile ground for? Race conditions around file creation, deletion, permission setting, and so on. The original code accounted for decades of hard-learned lessons in that space. The Rust rewrite did not:https://t.co/yp5WJxQZF1 — lcamtuf (@lcamtuf)May 4, 2026 (A cikk nyomokbanMesterséges Intelligenciaáltal szolgáltatott adatokattartalmaz, így a tartalmát érdemes duplán ellenőrizni!) "A memóriabiztonság fontos előny, de nem helyettesíti a Unix-jogosultságok, szimbolikus linkek, ideiglenes fájlok és race condition minták körül évtizedek alatt összegyűlt tapasztalatot." Ami működik, ne javítgasd! Ha ismert TOCTOU hibák vannak, akkor azokat kell kijavítani, és nem újraírni az egészet, mert abban meg ismeretlen hibák lesznek. TOCTOU hiba pont az újraírt verzióban jött be, az eredetiben nem volt. És egy rahedli csomó másik - főleg hibakezelés esetén - eltérő viselkedés is van, aminek lehetnek biztonsági következményei. Régóta vágyok én, az androidok mezonkincsére már! Mikor a 25.10-ben bejött, és ment a "hülye kóderek" puffogás, már akkor mondtam, hogy egyrészt még önbevallás alapon sincs kész, mert egy csomó coreutilsos teszt még vagy failel vagy skippelve van (ilyen 20% körül rémlik), és szerintem már akkor mondtam, hogy az még csak az a pont, ahol el lehet gondolkozni azon, hogy az a tesztkészlet elég-e, vagy valójában hiányos. És hát ez megerősíti, hogy valójában hiányos. :) Mármint nyilván, eleve nem kéne bele race conditionos funkcionális hibákat tenni, de azért az urak, akik most mondják, hogy hát mi tudjuk, hogy ezzel óvatosnak kell lenni, mert már nehezen megtanultuk (érts, mi is beszoptuk ezt számtalanszor), azok az óvatosság mellett írhattak volna ezekre tesztet is pl. :) Röviden: a rust, az AI, meg a jóégtudja, milyen újítások még  egy középszar kódert sem képesek megbízhatóan helyettesíteni, nemhogy szoftverfejlesztő mérnököket.Ne nyúljon hozzá az, aki annyire nem ért hozzá. Aki értene, annak derogál Rust-hoz nyúlni, úgyhogy róka fogta 22-es csapdája... A hype-on kívül miért követelmény a rust? Vagyis ha van, aki értene hozzá, és megcsinálná C-ben jól, azzal mi a baj? A helyzet állandóan változik, és ha azt akarjuk, hogy gondolkodásunk megfeleljen az új helyzetnek, akkor tanulnunk kell. – 毛泽东 Más szakmában is előfordulnak olyan előírások, amikre egy gyakorlott szaki azt mondja, az hülyeség, mert ő úgy is megcsinálja jól anélkül az előírt technika nélkül. Aztán néha jön a pofára esés. Melyik könnyebben megvalósítható? Jól képzett, mindig hibátlan munkát adó szaki találása vagy olyan eszköz előírása, ami egyes súlyos hibákat már kapásból kivéd? Lehet azt mondani, hogy a Rust az rossz. Még lehet is benne valami. De olyan eszközöket, amit boldog-boldogtalan beépít mindenhová, aztán gyakran jól magára is hagyja, átírni olyan nyelvre, ami védőhálókat ad bizonyos támadási felületek ellen, szerintem nem haszontalan. Mert vannak divatprogramozók, akik azt hiszik hogy az aktuális szarjukkal a világ minden problémáját megoldják. Az aktuális szar volt már a Visual Basic, a C++, a Java, a PHP, a C#, a javascript, a Ruby, a webassembly, a python, meg a go is. Most éppen a Rust meg a prompt engineering. Aztán a végén mindig kiderül, hogy az egyszerű szerkezetek jobban működnek, és hogy a nehézség nem biztos hogy abból jön, hogy valamit hány SORBAN meg milyen NYELVEN írunk meg, hanem a program magas szintű tervezésében, a rétegek megfelelő elválasztásában. Az absztrakciókkal csak máshová toltuk a komplexitást. Nyilván legyen egy nyelvben azért alapvető kényelmi támogatás, pl. kezeljen már magától stringeket meg tömböket anélkül hogy segfaultolna. C-ben már meg van csinálva jól :) Pont ez a mondanivalóm lényege. A helyzet állandóan változik, és ha azt akarjuk, hogy gondolkodásunk megfeleljen az új helyzetnek, akkor tanulnunk kell. – 毛泽东 A Rust igerete az, hogy nem lehetseges memoria korrupciot illetve data race-t krealni benne, illetve amikor feladja a runtime, az is ellenorzott modon tortenik. Tehat mondjuk nincs olyan, hogy szetszall a programod segfault-tal es meg egy nyuves stack tracet sem kepes produkalni. Az egesznek a tetejebe nem garbage collector alapu. Ezt az elterjedt systems programming nyelvek kozul (C/C++/Go) egyik sem tudja nyujtani.  Ez a mezesmadzag resze a dolognak. Ha visszanezunk, hogy az elmult 25 evben a coreutils-ban hany olyan CVE szuletett, ami a fenti hibakra vezetheto vissza, illetve hozzacsapva azt a tenyt, hogy az ilyen hibak egy jelentos resze hasznalhato arra, hogy kulonfele exploitokat hozzanak letre, szerintem nem kerdeses, hogy van ertelme utni a vasat. Nyilvan ez az audit ravilagit arra, hogy a coreutils (meg amugy mindenfele szoftver) tartalmaz implicit elemeket, amik barmilyen atirasnal problemakat jelentenek. Pont ezek az implicit elemek tesznek barmilyen ujrairast kockazatossa. Ertsd: ha C-ben kellene ujrairni a cuccot, ezeket hibat akkor is elkovetnenek. Arra mindig ravilagit egy ilyen tortenet, hogy mennyire cargo cult alapokon mukodnek projektek. Ez termeszetes, tudni kell vele megbirkozni. Vannak amugy pozitivumok is, mert sokszor ilyen szituaciokban derul ki, hogy be van epitve egy csomo olyan safety, meg fallback, aminek mar zero relevanciaja van es csak a komplexitast noveli, a teljesitmenyt rontja. Ha adottak feltetelek a projekt vegigvitelehez, szerintem nincs itt semmi latnivalo. Ellenben teljesen jogos a disztribuciok reszerol, ha csak irgalmatlan mennyisegu teszteles es audit utan kezdik el hasznalni. Szerintem azzal a résszel is érdemes foglalkozni, hogy milyen fajta versenyhelyzetekről van szó. Véletlenül nem mélyebb tervezési hibák ezek a Unix-szerű rendszerekben? Biztos lehetne tanulni belőle. Csak én érzem úgy, hogy a core utils biztonsági hibái nem túl relevánsak, mikor ezek user joggal futtatott helyi programok? Amire a cp programot rá tudom bírni, azt közvetlenül beleírhatnám egy binárisba, és úgy is futtathatnám. Vagy vannak olyan rendszerek, ahol coreutilst futtathatok, de általam kreált binárist nem? Nyilván vannak, de ez mennyire gyakori eset? coureutils azért tartalmaz egy-két érzékeny programot is, ami akár user joggal is futhat, de root is használja, sőt, elsősorban root (pl. chown, chmod chgrp, mknod). Rootként futtatva ha valamit elkefélnek, tudnak hülyeséget csinálni. Ezt az elterjedt systems programming nyelvek kozul (C/C++/Go) egyik sem tudja nyujtani. A C++ tudja, ha értelmesen (C++ módon) van használva. Csak stack allocation, RAII. Nyilván ha C kóddal keverik, akkor nem. Ez a legnagyobb bűne (meg hogy 20x annyit tud, mint amennyi az átlagprogramozónak kellene, és ha már tudja, akkor valaki el is kezdi használni). Az 'ertelmes' szonak a jelentesen nagyon sok mulik. Az, ahogy a c++ standard meg van fogalmazva, tele van olyan esetekkel, amik undefined behaviour-t eredmenyeznek. Es ezeknek a forditasi ideju ellenorzeset egyetlen altalam ismert tool sem tudja megcsinalni. Es ez igaz, akkor is ha kivonom a szabvanybol a C-t. Pelda: "Two actions arepotentially concurrentif The execution of a program contains adata raceif it contains two potentially concurrent conflicting actions, at least one of which is not atomic, and neither happens before the other, except for the special case for signal handlers described below [omitted]. Any such data race results in undefined behavior." Kivancsi lennek arra, hogy hany oldalas az a specifikacioja az 'ertelmes' kodolasnak, ami gyakorlatban alkalmazhato es kikenyszeritheto, hogy UB-mentes a program. Ehhez kepest Rustban, ha elo tudsz allitani egy fent definialt data race-t, akkor talaltal egy hibat a forditoban es ki fogjak javitani, mert az egy bug. Erre nem vennek teljesen merget, de ha jol emlekszem, a Rust ownership modellrol matematikailag igazolva van, hogy data race mentes. Masik pelda: Nem vagyok teljesen meggyozodve, hogy ez teljesen beleesik-e az 'only stack allocation' kriteriumodba, de vizsgaljuk vegig a ket esetet: All-in-all: en oriasi rajongoja vagyok a c/c++-nak, de ezt a vilagot mar meg kellene haladni, mert egy nagyon regi dolog. A Rust rengeteg azota megszerzett tudast beepitett es matematikailag kizar egesz problemaosztalyokat, amikre jo esetben is csak fel- es almegoldasok leteznek c++-ban, es ezekrol a problemaosztalyokrol tudjuk, hogy nagyon kenyesek security oldalrol, mert exploitokat lehet az azokat tartalmazo programokra epiteni, debuggolni oket meg kifejezetten maceras. Data race-ről nem tudok nyilatkozni, nincs akkora tapasztalatom többszálú kódokban. Csináltam már, de régen volt, manapság inkább embedded kódokat írok, ott meg nincs. A stack allocation alatt nyilván nem azt értem, hogytechnikailagsem használod a heap-et, hanem azt, hogy be van csomagolva egy olyan objektumba, ami ezt kezeli a színfalak mögött. Ha meg hülyeségre lenne kényszerítve, dob exception-t. Es milyen exception-t dob az a C++ kod, amikor van egy javaleak-ed egymast shared_ptr-eken keresztulhivatkozo objektumokbol? Hogyan kepzeled el ennek a kivetelnek az eldobasat?  Meg jobb kerdes: hogyan kepzeled el ennek a kivetelnek a kezeleset? Marmint ez a kivetel tipikusan scope-ok vegen jonne letre valamilyen destruktor futasa utan. Se a hasznalata, se a kezelese nem lesz egy faklyasmenet. Tudom, hogy divat fikazni a Rust-ot, de szerintem inkabb a technologiat korulvevo zelotakra kene loni, akik nem ertik a tradeoffokat. Ha a nyelvet magat nezed, akkor van ertekes unique selling point-ja, amit egyik masik mainstream systems language nem tud, szerintem errol felesleges vitatkozni. Azt mar minden projekt dontse el maganak, hogy neki megeri-e szenvedni az atallassal, mert egesz biztosan nem pici melo. Itt 25 év coreutils tapasztalat kéne, ami megvan a GNU coreutils projektnél. Random "szoftverfejlesztő mérnök" önmagában kevés lenne. trey @ gépház Itt legelső lépésben kompetenciahatárok felismerése lenne a feladat, tehát ha valakinek láthatóan a szoftverfejlesztés legegyszerűbb része, a kódolás is alig-alig megy, akkor nem áll neki újraírni a coreutils egyetlen komponensét sem, úgy általában véve nem nyúl ilyen szinten kritikus kódokhoz, még Rusttal és LLM-el felvértezve sem. https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/:) Ez jó régen volt! De a coreutils újraírók nyilvánvalóan nem olvasták. Lehet, hogy még nem is éltek... :D Ezzel azért lehet vitatkozni.Van, amikor jogos valamit 0-ról újraírni. Lehet hogy kevesebbszer, mint ahányszor előfordul a gyakorlatban, de van ilyen eset. Azért újraírni, hogy MÁS nyelven legyen megírva, na az egy ökörség. 26.04-ben vissza lehet állni az eredeti coreutils csomagra? A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk. Hogyne. Átírod a sources.listet Debian repora :D Release notes egyértelműen taglalja, támogatott a GNU coreutils is, nem kell mókolni semmi külső repóval: https://documentation.ubuntu.com/release-notes/26.04/summary-for-lts-users To switch to GNU coreutils: sudo apt install coreutils-from-gnu --allow-remove-essential Köszi! A magyar ember jelképe a hátrafelé nyilazás. Vakon rohanunk a semmibe, miközben a múltunkat támadjuk. De, a tanulság pont az, hogy az alapvető rendszereszközök újraírása nem pusztán nyelvi kérdés, és a Rust önmagában nem váltja meg a világot, túl van hájpolva. Ezt egyébként mindig is lehetett látni. Örülök, hogy a Canonical kicsit lelassított ebben a Rust-buzulásban. A másik jó hír lehet treynek és nevergone-nak, hogy  a kedvenc Unityjük is megmenekülhet, aztírják átWayland/Wayfire-alapra. Igaz Wayland, és nem X11, de hát semmi nem tökéletes. “Linux isn't an OS, it's a troubleshooting sim game.”(a YouTube commenter) treynek és nevergone-nak, hogy  a kedvenc Unityjük is megmenekülhet Br0, nem használok Unity-t kb. 10+ éve, amióta nem az az alapértelmezett, Br0. Én mindig a default környezetet használom. Amikor az Unity volt, az Unity-t. Amióta GNOME 3 Shell, azóta az. Tévképzetek vannak a fejedben. Br0. trey @ gépház