Electron 6.0.0

Byla vydána verze 6.0.0 frameworku pro vývoj multiplatformních desktopových aplikací pomocí HTML, CSS a JavaScriptu Electron (Wikipedie, GitHub). Electron byl původně vyvíjen pro editor Atom pod názvem Atom Shell. Dnes je na Electronu postavena celá řada dalších aplikací.

31.7.2019 16:55 | Ladislav Hagara | Nová verze

Komentáře

[Jardík]

A všechno to jsou pomalé jednovláknové šmejďárny s GUI jak omalovánky, které nezapadá do systému.

[Josef Kufner]

Jednovláknové je například i Qt a Gtk+

[xkucf03]

Tak samotné GUI bývá typicky jedno-vláknové a všechny GUI události se odbavují v jednom. Ale běžně jde pouštět vlákna na pozadí, která něco provedou, a pak předají výsledek do GUI, kde se to synchronizuje, události se poskládají do jedné fronty a postupně provedou/vykreslí.

[Josef Kufner]

Však to jde i v JavaScriptu.

[Ovoce]

A všechno to jsou pomalé jednovláknové šmejďárny s GUI jak omalovánky, které nezapadá do systému.

Ale na druhou stranu zase aspoň zabíraj 250 MB na disku.

[Petr Ježek]

Přichází čas, kdy se mi něco podobného začne hodit.

[Rezza]

Jo, teď mě jedna taková padá a když padá, tak vytváří core dump a to je pak noťas na pár minut nepoužitelný :D.

[Bedňa]

Mno ja som v práci musel inštalovať CentOS a prvá spustená aplikácia segfaultovala to som ešte nevidel, zrejme by si mal zmeniť distribúciu a aj zamestnávateľa.

[Pepa]

No mame ted jednu webovou aplikaci kterou chceme dostat na desktop, tak mozna je to cesta...

[Bedňa]

To skôr odporúčam NW.js, tam naportuješ aplikáciu bez nejakej alchýmie.

[k3dAR]

nebo bash "script" s:

yad --html --browser --uri https://www.abclinuxu.cz

[xkucf03]

BTW: dřív měly prohlížeče možnost spuštění v „aplikačním režimu“, kdy otevřeli jedno okno s jednou stránkou bez nějakých dalších ovládacích prvků a v samostatném profilu. Proč se nepoužívá tohle a má každý potřebu balit ke své aplikaci i celý prohlížeč? Taková aplikace by pak mohla mít jen pár kilobajtů a nemusela by se ani instalovat.

[Bedňa]

Také základné dva body sú:

1.) Aplikácie nad webkitom, majú oprávnenie k systému rovnaké ako hocijaká iná aplikácia.

JavaScriptová aplikácia na Chrome/Chromium má práva len na časť týkajúcu sa prehliadania internetu. Čiže si vie ukladať dáta v rámci prehliadača a nikde inde nemôže. Keď chce spustiť kameru, tak si o to musí explicitne vyžiadať práva od užívateľa. Ak by chcela šiahnuť niekde mimo prehliadača rovnako to musí povoliť užívateľ.

2.) Problém s meniacim sa API, takže to zapadá do dnešnej posranej doby deravých kontajnerov.

[xkucf03]

To první by bylo řešitelné – stačí mít v tom balíčku metadata, která řeknou, kam aplikace chce mít přístup – a při instalaci nebo spuštění to potvrdíš. Asi by k tomu mělo existovat samostatné běhové prostředí nezávislé na prohlížeči – ale pořád může být v systému jen jednou a ne přibalené ke každé aplikaci.

To druhé je problém, úpadek no…

[Bedňa]

Mozilla kvôli bezpečnosti úplne zahodila XUL a celý FirefoxOS, proste je tam stále priestor pre zneužitie vďaka bugom. Google sa rovnako bráni spojiť prehliadač a natívne aplikácie dokopy. Firefox má podľa mňa navrch vďaka Rustu, tak možno raz sa dočkáme nejakej obdoby XUL.

Aj ten druhý bod je riešiteľný, ako je napríklad Evolučné API, ktoré Google sem tam používa, tuším Flutter? Čiže chovanie API sa nemení, len sa pridáva funkcionalita a keď je sa zistí, že nevyhovuje, tak sa spraví nová funkcia ktorá to vyrieši a stará ostane ako bola. Funkcia sa odstráni až po zistení, že to fakt už nikto nepoužíva.

[deda.jabko]

Mozilla kvôli bezpečnosti úplne zahodila XUL

Firefox má podľa mňa navrch vďaka Rustu, tak možno raz sa dočkáme nejakej obdoby XUL.

XUL je nebezpecny by design, protoze bezpecnost nijak koncepcne neresi IIRC, takze jazyk, ve kterem je to implementovane to nezmeni, ani v nejmensim.

Google sa rovnako bráni spojiť prehliadač a natívne aplikácie dokopy

A je to rozumne rozhodnuti, protoze propojit to je idealni cesta, jak udelat diru do systemu jako vrata. Nekteri si mozna vzpomenou, jak spektakularne se toto propojeni nepovedlo s ActiveX, ... a pritom to na papire byl tak hezky napad.

[kralyk z abclinuxu]

IIRC problém s XULem byl hlavněv tom, že byl pomalý - příliš vyžadoval marhsalling dat atd. Záměr přechodu k Rustu je k tomu víceméně orotognální, bylo to IMO hlavně o tom, že "C++ nás s*re, už to v něm nechcem psát", řada vlastností Rustu vznikla víceméně organicky a/nebo serendipity.

[deda.jabko]

IIRC problém s XULem byl hlavněv tom, že byl pomalý - příliš vyžadoval marhsalling dat atd.

Toto je opet zcela ortogonalni problem. Navic nevim, jak moc je realny ve svete, kde nekteri povazuji Electron za dobry napad.

Hlavni problem XUL (z pohledu bezpecnosti) je ten, ze pluginy nejsou nicim omezene (IIRC, je to nejaky patek, co jsem se na to dival), a kazdy plugin si muze prizpusobit prohlizec podle svych predstav, coz je super vec, pokud mas nad tvorbou pluginu kontrolu. Pokud tu kontrolu nemas, vznika ti jednak bezpecnosti peklo a jednak jakykoliv zasah do prohlizece muze rozbijet out-of-tree pluginy.

Poznamka na okraj. Trosku to ukazuje, jak by asi skoncil bystroushaakuv utopicky objektovy svet, o kterem tu nekolikrat psal.

[xkucf03]

Podle mého je lepší bezpečnost řešit na úrovni operačního systému¹ pomocí SELinuxu, AppArmoru kontejnerů s omezenými oprávněními atd. Tzn. aplikace sice poběží pod daným uživatelem, ale nemá přístup ke všem jeho zdrojům (soubory, síť, sokety např. ssh-agenta atd.). Protože ono i když to běhové prostředí bude napsané v něčem „bezpečném“ jako Rust, stejně v tom můžou být chyby. Oproti tomu to řešení na úrovni OS má menší povrch, na který lze útočit, stojí na principu, že vše co není povolené, je zakázané, a dá se to napsat jednou a pořádně otestovat.

Případně by to šlo řešit i primitivním způsobem tak, že by každý reálný uživatel v systému měl několik doplňkových uživatelských účtů s omezenými právy, pod kterými by si mohl pouštět méně důvěryhodné procesy. Takže by stačilo mít protokol pro komunikaci s tímto podprocesem a ty pluginy by pak klidně mohly být obyčejné binárky, které si přes STDIO nebo nějaký soket s hlavním procesem posílají zprávy.

_{[1] jasně, v prohlížeči s mnoha současně instalovanými moduly si to musí řešit prohlížeč, ale teď se bavím o tom běhovém prostředí, viz výše, ve kterém se spouští právě jedna aplikace}

[kralyk z abclinuxu]

Podle mého je lepší bezpečnost řešit na úrovni operačního systému1 pomocí SELinuxu, AppArmoru kontejnerů s omezenými oprávněními atd.

To se přece nijak nevylučuje, naopak, to se vhodně doplňuje.

Nehledě k tomu, že ten OS a jeho userspace komponenty taky musí v něčem být napsané...

[xkucf03]

Šlo mi o to, že když bych měl spouštět nějakou nedůvěryhodnou aplikaci, tak bych asi spíš věřil mechanismům operačního systému než nějakému běhovému prostředí, které tvrdí, že ten kód bude mít jen omezená práva, ale přitom ten proces, v kterém to běží, má plná práva ke všem mým souborům a dalším zdrojům. Je to asi jako kdybys pouštěl třeba interpret PHP pod rootem a práva řešil vypnutím funkcí v php.ini – taky bys asi byl klidnější, kdyby ten skript neběžel pod rootem a omezená práva měl na úrovni OS.

[Bedňa]

Dať človeku oči a potom mu nasadiť slepecké brýle?

Táto doba je plná zlých nápadav.

Tieto nástroje by sa mali používať na testovanie a nie v produkcií. Potom to automaticky skĺzne do doby kde sme. Všetko beží v deravých kontajneroch. Odopretie práv aplikácií skončí segfaultom aplikácie, tak jej pre istotu dáme všetky práva a žijeme v nejakej umelej (vysnenej) bezbečnosti, ktorá nestojí za starý deravý groš.

[deda.jabko]

[1] jasně, v prohlížeči s mnoha současně instalovanými moduly si to musí řešit prohlížeč, ale teď se bavím o tom běhovém prostředí, viz výše, ve kterém se spouští právě jedna aplikace

Pro kontext: uz dve urovne diskuze pisu o XUL, ktere je blbe by design, ... a AppArmor nebo SELinux ti tu opravdu nepomuzou.

Podle mého je lepší bezpečnost řešit na úrovni operačního systému

IMHO nejlepsi je resit bezpecnost na nejblizsim miste, kde to jde, jinak hrozi, ze ti budou vznikat mista, ktera lze potencialne zneuzit.

Takže by stačilo mít protokol pro komunikaci s tímto podprocesem a ty pluginy by pak klidně mohly být obyčejné binárky, které si přes STDIO nebo nějaký soket s hlavním procesem posílají zprávy.

Jinymi slovy, musis mit definovane rozhrani.

Velka vyhoda pluginu postavenych na XUL je/byla v tom, ze muzou podstatnym zpusobem menit treba i vzhled prohlizece, rozsirovat jeho chovani zpusobem, ktery puvodni tvurce prohlizece nepredpokladal.

Velkou nevyhoda pluginu postavenych na XUL je/byla v tom, ze muzou podstatnym zpusobem menit treba i vzhled prohlizece, rozsirovat jeho chovani zpusobem, ktery puvodni tvurce prohlizece nepredpokladal.

Takze prohlizece se vydaly cestou web extensions, coz vede k tomu, ze sice prohlizec bude bezpecnejsi, ale nektere veci, proste nepujdou udelat, protoze to rozhrani to nepovoli.

Případně by to šlo řešit i primitivním způsobem tak, že by každý reálný uživatel v systému měl několik doplňkových uživatelských účtů s omezenými právy, pod kterými by si mohl pouštět méně důvěryhodné procesy.

To je takove docela humpolacke reseni a v praxi pouzitelne maximalne na osobnim pocitaci s jednim uzivatelem. Systemovejsi reseni by bylo mit capability-based OS.

[kralyk z abclinuxu]

Proč se nepoužívá tohle a má každý potřebu balit ke své aplikaci i celý prohlížeč?

Electron není pouze prohlížeč, ale je to Node.js + prohlížeč. V tom je celá ta pointa. (Neříkám, že to tak je dobře, jenom vysvětlení.)

[xkucf03]

Já vím, myslel jsem tím obecně to běhové prostředí. U Javy nebo Pythonu, Perlu, PHP atd. taky přece není normální a správné ke každé aplikaci to běhové prostředí přibalit (byť to někteří dělají). Aplikace je pak malé JARko nebo skript a spustím si je ve svém běhovém prostředí, které už mám nainstalované (a ve kterém mám třeba bezpečnostní aktualizace spravované mojí distribucí).

Když to vezmu do extrému, tak to už by se aplikace mohly distribuovat jako virtuálky pro KVM/Qemu, které by obsahovaly nějaké minimální jádro a Xka/Wayland a skrze VirtIO by tam byly protažené kanály pro práci např. s místními soubory nebo se sítí. Bylo by tam jasně deklarované, kam má aplikace mít přístup a víc by nemohla, protože by ji tam nepustil hypervizor. Nakonec by mi to přišlo lepší (a pro některé aplikace dobrá volba) než přibalovat k aplikaci prohlížeč+Node.js, což si podle mého bere z obou světů to horší – je to velké, neaktualizuje se to, uvnitř můžou být děravé knihovny a bůhvíco a zároveň je to běžná desktopová aplikace, která může vlastně cokoli (omezit by se musela dodatečně skrze nějaký Flatpak, Snap, AppArmor, atd.).

[deda.jabko]

Node.js + prohlížeč

Me na tom strasne dojima, ze to jsou dva JS enginy, ktere si mezi sebou vykladaji pomoci HTTP a jeden z nejkomplexnejsich baliku kodu, ktery se v dnesnich systemech pouziva a ktery implementuje nemale mnozstvi standardu, se pouziva jen jako renderovaci jadro, protoze banda hipsteru umi jenom HTML + JS.

Zajimave je, ze v minulosti byly pokusy (NeXT, Apple) renderovat uzivatelske rozhrani pomoci postscriptu, coz mi prijde jako lepsi reseni nez HTML, ale z nejakeho duvodu se to nechytlo... tak si to ted musime vyzrat do horkeho konce s HTML.