Hibás Google Chrome frissítés lehet az okozója a rejtélyes Mac Pro hibáknak

Bug

Hétfőn számos hollywoodi film- és tévéstúdióban nehezítette a munkát az a jelenség ami a Mac Pro gépek meghibásodásához vezetett. Először vírusfertőzésre gyanakodtak, de később egy Google Chrome frissítés lett gyanús. A Google egyik szakembere megerősítette a gyanút:

We recently discovered that a Chrome update may have shipped with a bug that damages the file system on macOS machines with System Integrity Protection (SIP) disabled, including machines that do not support SIP. We've paused the release while we finalize a new update that addresses the problem.

Az érintett gépek javításához szükséges lépések megtalálhatók a Google alkalmazott fórumpostjában.

( log69 | 2019. 09. 26., cs – 08:58 )

"..damages the file system..." - ezt hogy? :)

nem érzitek hogy az felé megyünk már jó ideje, hogy nagyobb veszélyt jelentenek a produktivitásra a nagy cégek update-jei mint a vírusok, főleg olyan gépeken ahol nem jellemző sűrűn az idegen fájlok hurcolása? úgy érzem a felhasználó lekerült régóta az ipar figyelmének polcáról, leginkább a profit ami számít - részemről teljesen hitelét vesztette az összes giga cég - bármikor jobban megbízok egy kisebb cég munkájának minőségében, logikusabb is mert nekik jobban kell versenyezni.

Azért a SIP kikapcsolása is érdekes egy production gépen. Értem én, hogy így kényelmesebb ezt-azt installálni, de azért legyen már annyi felelősségtudat, hogy karbantartás után visszakapcsolják a védelmet! Mondjuk azt nem igazán értem, hogy egy böngészőnek miért van szüksége olyan software komponensre, ami befolyásolni tudja egy filerendszer állapotát.

Ave, Saabi.

Ahol az update-et nem az OS service-e végzi, azt azon helyben ott kell hagyni. Ahol egy böngésző a letöltések és a saját beállításain kívül tud írni, azt azonnal ott kell hagyni.

Ez olyan, mint hogy nem használsz úgy npm-et a rendszereden, hogy a felhasználód tudja módosítani a package-eket. Win-en ezért nem használnak az emberek pl. Electron-ra épülő érzékeny appokat, mert kiválóan lehet így pl. jelszavakat vagy bankkártya adatokat lopni.

Ahol az update-et nem az OS service-e végzi, azt azon helyben ott kell hagyni.

Minden Wines alkalmazás kedveli ezt. (másrészt meg aki az LO topikokban mindig beírja, hogy mekkora szar az LO, mert a 3rd party szutyokkal "tisztított" gépén frissítéskor bekéri az előző verzió msi fájlját, szintén...)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Nekem Fedorán/Ubuntun az LO nem kér msi-ket :)

De tényleg, miért is kell neki? Előbb uninstallt nyom és ahhoz kell a régi msi? Linuxon a csomagkezelőnek megvan a fájl lista, gondolom ebből okoskodik az rpm/dpkg/...

De akkor sem értem, Win-en is túlélhetné a régi msi nélkül is. Tudja, hogy melyik könyvtárban van a lényeg, azt kell törölni. Minden proginak ott kell hagyni a sok 100MB-os "felesleges" szutykát?

De tényleg, miért is kell neki? Előbb uninstallt nyom és ahhoz kell a régi msi?

Ha a Product Code megegyezik (vagy az Upgrade Code? valamelyik UUID a Property táblában :) ), akkor a korábbi vezióra (major/minor/patch hármassal van azonosítva) tol egy törlést.

Ami miatt viszont kell neki az installer (nézz szét a C:\Windows\Installer mappában :) ) az a tranzakcionális telepítés: ha a telepítés pillanatában fut a program, akkor ugye lockolt a fájl és nem tudja felülírni; ilyenkor nyafog az újraindítás miatt, a leállítás közben meg befejezi a telepítési műveletet (ha meg nem sikerül, indításkor visszavonja). A helyi másolat meg azért kell, mert 1) ilyenkor már nem biztos, hogy van hálózat, ha esetleg onnan telepítettél vagy 2) a tényleges telepítést egy service végzi, ami nem a telepítést elindító user nevében fut. (a hálózatról telepítés meg egyébként is valid use case, de a GPO-ból telepítésnél meg kb. kizárólagos).

Tudja, hogy melyik könyvtárban van a lényeg, azt kell törölni.

Hátőőő... NSIS-nél (ahol neked kell összeraknod az uninstaller-t is) bevett szokás ez, hogy simán rm -rf a telepítési könyvtárra (meg utána az uninstall registry keyekre, amiket kézzel hoztál létre)... ami addig szépen működik, amíg senki más nem bántja azt a könyvtárat (pl. egy plug-in telepítője), az szép tud lenni, amikor független komponensek gyilkolják egymás fájljait :) [tudom, én is csináltam ilyet...]

Aztán ehhez ha hozzáveszed az msp-ket (msi patch fájlok), akkor még rosszabb a helyzet.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"Ahol az update-et nem az OS service-e végzi"
Egy 3rd party app frissítése miért függjön az OS frissítéskezelésétől? Lehet, hogy totál más dependency resolutiont használ. Lehet, hogy saját maga mellé csomagolja a függőségeit. Lehet, hogy totál más verzióstringeket és algoritmust használ a vendor ahhoz, hogy megállapítsa, mi friss, meg mi nem. Aki platformfüggetlen akar lenni, nem bízhat sok mindent az OS-re.

" a felhasználód tudja módosítani a package-eket. "
Itt pont arról van szó, hogy a rendszermódosító nem a felhasználó jogaival fut, hanem rootként.

"Win-en ezért nem használnak az emberek pl. Electron-ra épülő érzékeny appokat, mert kiválóan lehet így pl. jelszavakat vagy bankkártya adatokat lopni."
Jaja, Slack és társai, amik Windows Store-ból települnek, azok nem is léteznek, értem én.

"Ahol egy böngésző a letöltések és a saját beállításain kívül tud írni, azt azonnal ott kell hagyni."
Szóval browsert se használjunk, hiszen az érzékeny adatokat a felhasználó által írható helyre helyezheti, hiszen máshoz nincs joga.

"Egy 3rd party app frissítése miért függjön az OS frissítéskezelésétől?"

Úgy értem, hogy ne írjon mindenki magának mindenféle bugos updatert, hanem legyen valami központi cucc. Lehet Win Store, Gnome Software, apt, Google Play stb.

"Itt pont arról van szó, hogy a rendszermódosító nem a felhasználó jogaival fut, hanem rootként."

Mi az az "itt"? Én épp az npm-ről csipogtam, amire válaszoltál.

"Jaja, Slack és társai, amik Windows Store-ból települnek, azok nem is léteznek, értem én."

Ha kibogozod, amit írtam, akkor ezek létezhetnek, de vagy nem érzékeny adatokat kezelnek vagy nem emberek (hanem lemmingek) használják :)

"Szóval browsert se használjunk, hiszen az érzékeny adatokat a felhasználó által írható helyre helyezheti, hiszen máshoz nincs joga."

Nana, azt írtam, hogy a letöltések könyvtárba írhat. Ez olyan, mint a média lejátszó sem szabad, hogy zenéken vagy videókon és a saját beállításain kívül mást is lásson a fájlrendszeren.

A hibat nem a SIP kikapcsolasa okozza (en pl. nem ismerek olyat, aki nem kapcsolta ki. Ha bekapcsolod, a rendszer bezar, nem tudsz kodot injektalni a Dock.app-ba, se a Terminal.app-ba sott, az Xcode.app-ba se. Nem tudom felulcsapni peldaul az ezereves basht. Nem tudom atirni a launchd plistjeit, nem megy a DYLD_INSERT_LIBRARIES sem). A hibat az okozza, hogy a google updatere rootkent, letorli a /var -t. Nekem 3 gepbol 2 gepen hianyziott tegnap este a /var symlinkje. Meg szerencse, hogy csak ritkan kell rebootolni.

Hát... ööö... lehet, hogy ciki, de nekem történetesen nincs kikapcsolva a SIP.
Én a bash-t egy zsh-val "csaptam" felül, de miért is kellene tudnom ehhez írni a védett rendszerkönyvtárakba? Lehet az a shell mondjuk a /usr/local/-ban, vagy akár a $HOME/bin-ben, mindegy. Amúgy a fent jelzett teendőket neveztem én karbantartásnak, melyek nem kellene hogy napi rendszerességgel megtörténjenek. Arról már nem is beszélve, hogy miért kell a Google updater-nek rootként futnia? Ahhoz, hogy frissítsen egy böngészőt? Ha valaki root jogot ad minden vacak programnak, az ne csodálkozzon, ha a rendszere összedől. Ehhez nem kell macOS-nek lenni, ez így volt és így van minden létező UNIX és UNIX-szerű oprendszernél.

Ave, Saabi.

te jó isten, dehogy bazmeg. Én levágnám a kezét, aki a SIP-et kikapcsolja. Ha valamit akarsz turkálni akkor ott a root.

túl sok itt a dózeres csóka, akik nem értik a unixot...
Ezért szokom mondani, hogy itt Agyarországon még a linuxosok is windózt használnak...

--
GPLv3-as hozzászólás.

úgy érzem a felhasználó lekerült régóta az ipar figyelmének polcáról, leginkább a profit ami számít

Hát igen, és ezesetben ráadásul a profit nem közvetlenül a felhasználótól jön, így pont annyira veszik figyelembe a te érdekeidet, mint amennyit fizettél a termékért...

A durvább, amikor egy erősen fizetős termékkel történik hasonló. Mert ugye ott sincs nagy beleszólásod: automatikusan kapod amit (teszteletlenül) a gépedre tolnak.

És ez már elég régóta így megy. :|

--
zrubi.hu

A Google keresője 1998-ban indult, akkor is év végén. (igaz akkor beta fázisban). 2001-ben még más termékük nem is igazán volt. (talán a Google Toolbar még). Az XP kiadásakor még egy apró cég voltak, 400 alkalmazottal.

A Google miatt inkább a rövidebb időintervallum lett elfogadott. Korábban a Microsoft 2-3 évente adott ki egy beta színvonalú programot, amit aztán különböző patchekkel fél-egy év alatt kb. rendbe rakott, míg a Google 6 hetente ad ki új verziót, így a ami aztán átlag 1 héten belül kap egy hibajavító csomagot.

Illetve a Microsoft programoknál az Office XP-re történő átállás előtt volt időd megvárni az SP1-et hozzá. Emlékszem, hogy abban az időben sok rendszergazdától hallottam, hogy akkor frissítenek bármilyen Microsoft terméknél a következő kiadásra, ha megjön hozzá az SP1, mert addig csak a gond van velük.

Ez egy 2018 Júliusi cikk. 2018 Októbere óta, amióta a Firefox 63 már támogatja a shadow dom api-t, azóta már annyira gyors, amilyen gyorsra írják a Mozilla szakemberei. Persze lehet kicsit hamar álltak át a Shadow dom-ra a youtube-nál, hiszen ahogy elnézem, 2018 márciusában lett meg a szabvány, várhattak volna, míg többen implementálják.

Én rendszeresen fejlesztettem szintén polymer js-ben (főleg a 2-es verzióban). A régi böngészők támogatása úgy van megoldva, hogy amit a régi böngésző nem támogatott natívan, azt egy JS átdolgozta olyan elemekre, amiket támogatott, ez nyilván sokat lassított rajta.

Nem érted a dolgot, nem polyfill a probléma.
Hanem az, hogy a Chrome olyan API használatával implementálja a YouTube-ot, ami már deprecated, sosem volt szabvány, emiatt a Firefox nem implementálja (Shadow DOM v0 - https://caniuse.com/#feat=shadowdom).
A Firefox Shadow DOM v1-et támogat.
A Shadow DOM v0-t majd 2020 februárjában veszik ki a Chrome képességei közül:
https://www.chromestatus.com/feature/4507242028072960
Senki más nem is támogatja, de a Google okosan úgy intézte valahogy, hogy a YouTube ezt az API-t használva készüljön el.

Most gyorsan lekértem a PolymerJS verziószámát Firefox alatt, mert a kódot még csak benézhettem: https://imgur.com/r8AULSq

Azt írja 3.3-as PolymerJS-t használ, abban pedig már rég nincsen Shadow DOM v0. Biztosan volt olyan időszak, amikor volt ezzel gond, de most sem érzésre, sem a látott kód alapján nem lassabb.

( Jason v | 2019. 09. 27., p – 20:30 )

Jó jó, de hol van evone kárörvendeni?