Kial Vi Devas Eviti Snaps, Flatpaks kaj AppImages
Se via Linuksa distribuo uzas tradician pakaĵadministrilon (ekzemple, apt en Debian Linukso), vi povas fari sekurecan revizion ekzamenante la fontkodon de ĉiu pako instalita en via sistemo. Ĉi tio daŭros longege, ĉar ĝi estas tiom da pakoj... Sed almenaŭ vi revizios ĉiun programbibliotekon nur unufoje. Tio estas ĉar en tia sistemo ĉiu biblioteko estas trovita nur unufoje, kaj reuzata en ĉiuj aplikaĵoj kiuj bezonas tiun bibliotekon per dinamika ligo. (Ne absolute tiel, sed superforte.)
Ĉu vi scias, kio estas multe pli malbona? Uzi pakaĵadministrilon en kiu ĉiu pakita aplikaĵo venas kun ĉiuj siaj dependecoj. Tiam pakaĵoj estas multe pli grandaj, kaj ili ripetas la samajn bibliotekojn, anstataŭ reuzi tiun jam instalitan en via baza sistemo.
Hodiaŭ neniu plu havas paciencon por la sendanka laboro de pakado de programaro, do ili serĉas ŝparvojojn.
Bildaj pakoj
En ĉi tiu artikolo, mi uzos la esprimon "bildaj pakoj" por rilati al ĉi tiu speco de pakaĵoj - ampleksante snaps, flatpaks, appimages kaj docker images.
La programlingvoj Go kaj Rust, kiam ili estis novaj, ne povis dinamike ligi bibliotekojn; ili nur funkciis kompilante la bibliotekojn rekte en la binaron de la apo. Ĉi tio damaĝas sekurecon en du manieroj: 1) kiam cimkorekto en biblioteko estas distribuita, la programo daŭre uzas la bugversion kiu estis statike ligita; 2) estas pli malfacile scii, kiu versio de biblioteko estas uzata de la aplikaĵo duuma.
Kiam unue aperis Linuksaj distribuoj, ĉiuj konsciis, ke sekureco estas ilia ĉefa laboro. Se vi elektas ruli Debian, vi sciis, ke via programaro estis validigita, vi povus fidi ĝin. Debian stabila malrapidas ĝisdatigi programaron, vi daŭre rulas la saman version de programo dum longa tempo, kio donas al vi pli da kialo por fidi tiun version. Ĉi tio estas bona, sed ĝi enuigas la nuntempajn spektantarojn, ĉar ilia konsumismo ankaŭ manifestas sin en konstante ĝisdatiganta la labortablan medion kaj vidante la plej novajn sencelajn ikonojn, bildojn kaj animaciojn. En la 2000-aj jaroj Linukso kreskis preter grupoj da homoj sufiĉe prudentaj por aprezi liberan programaron. Multaj kreintoj de malfermkoda programaro hodiaŭ uzas komputilojn de Apple anstataŭ Linukso, permesante al Apple spioni ilin konstante. Tio estas ĉar la prioritatoj de ĉi tiuj homoj mem eraras.
Specifaj Snap-aferoj
Eĉ en ĉi tiu malbona spirito, la komunumo protestis kontraŭ la insisto de Ubuntu antaŭenpuŝi siajn Snap-pakaĵojn. Jen listo de la problemoj kun Snap, de malplej gravaj ĝis plej gravaj:
- Canonical estis kritikita ĉar la servilo de la pakaĵvendejo estas proprieta programaro. (Mi ne certas, ke iu ajn alia volus reuzi tiun malantaŭan finon ĉiukaze.)
- Canonical devigas snap pakojn al ĉiuj Ubuntu-uzantoj; Firefox sur Ubuntu estas nuntempe pako snap.
- Snap-pakaĵo estas pli malrapida por komenci – kaj mi ne scias ĉu tio povas esti helpita, ĉar la plej multaj snap-pakaĵoj devus ruliĝi en sablokesto (kiu rezultigas pli bonan sekurecon) kaj ĝi estas multe pli granda programara blobo kun ĉiuj ĝiaj dependecoj.
- Ĉiuj snap-pakoj estas multe pli grandaj ĉar ili enhavas ĉiujn siajn dependecojn, malŝparante diskospacon.
- Canonical decidis, ke la ĝisdatigo de snap-pakoj estu tute aŭtomata; en ĉi tiu paŝo ili forgesas, kiu estas ilia spektantaro, ĉar Linukso-uzantoj volas esti en kontrolo de sia komputilo, anstataŭ kontrolita de grandaj teknologiaj kompanioj.
- Kiel ni vidis antaŭe, snap-pako enhavas ĉiujn ĝiajn dependecojn, igante sekurecan revizion koŝmaro.
Ĉi tiuj aferoj estu rezervitaj nur por nepopulara programaro. Ekzemple, vi volas frue adopti ion, kio ne estis pakita; la programisto, kvankam ŝi ne havas tempon por paki, faris snap-pakaĵon; do vi kontraŭvole uzas ĝin (fidante la programiston).
Linux Mint estas distribuo bazita sur Ubuntu, sed ili vidis la skribaĵon sur la muro kaj decidis ne akcepti snap-pakojn. Ĉi tio signifas, ke ili faras la laboron, kiun Ubuntu nun rifuzas fari: ĝuste meti Firefox en pakaĵon .deb. Plue, Mint komencis labori pri "Debian Edition", kiu ne baziĝas sur Ubuntu. Mint rimarkas, ke por Linukso-distribuo ekuzi bildpakaĵojn anstataŭ sia tradicia pakadministranto... estas terure misgvidita kaj havos sekvojn.
Kaj nur 3 horojn post kiam mi skribis "havos sekvojn"... Mi kaptis vorton pri la okazaĵo:
La okazaĵo
Jutuba filmeto: Malware malkovrita en la Snap-butiko de Ubuntu
Esence, iu fiulo alŝutis snap-pakon de kripta programo, kiu petis uzantojn pri ilia plej baza kripta pasvorto, kaj iu perdis dek mil dolaroj tiamaniere. La programo teorie eble ankaŭ legis hejmajn dosierojn de la uzantoj. Canonical instigas ĉiujn kaj iun ajn fari snap-pakaĵojn kaj alŝuti ilin al sia snap-vendejo, sen sekureca revizio.
Preskaŭ ĉiuj pensas, ke snap-pakaĵoj estas sablokestaj (sen aliro al kelkaj aferoj en la sistemo), sed la vero estas, sablokesto estas ĝuste rekomendita, sed povas esti malŝaltita de la persono faranta la pakaĵon. Tiel la video ricevas komentojn kiel ĉi tio:
@act.13.41: La tuta kialo, kiun ni ricevis por havi snap-pakoj disponeblaj NUR en la Ubuntu Snap Store, estis la sekureco de la programoj. Ĉi tio neniam devus okazi. Kaj tio estas fina.
Ĉu tio povus okazi en apt?
Ĉu ankaŭ malware povus invadi tradician pakaĵadministradon? Jen 2 bonegaj komentoj pri tio, el la supra video:
de @skynetisreal: Tipa kazo de kvalito aŭ kvanto. Tiuj estas elektoj, kiujn vi devas fari kiel deponejo prizorganto.
de @knghtbrd: Jes, snap estas malbona, sed ĉi tiu problemo povus ekzisti sur flatpak, ĝi okazis en PPA-oj, okazis en hazardaj speguloj de fidindaj distribuoj... Ĝi eĉ povus okazi en la AUR se iu estus singarda aŭ lerta. Vi devas esti damne singarda, kie vi ricevas vian programaron.
La ĉefa deponejo de Debian neniam havis malware en ĝi – sed hazarda spegulo estis hakita kaj ricevis iom da malware en ĝi unufoje. Tial ĉiu Debian-pakaĵo estas kriptografie subskribita kiam ĝi estas alŝutita. Post kiam alŝutite, la subskribo estas kontrolita, protokoloj registras kiu ŝlosilo subskribis ĝin, la pakaĵo estas haŝita kaj la haŝo estas stokita en la paklisto. La listo kaj eldondosiero tiam estas subskribitaj por malhelpi mistraktadon de deponejoj. Por meti malbon-programon en la pakaĵaron de Debiano postulas ricevi ies GPG-ŝlosilon aŭ ricevi malican programon per la procezo de Debian, kiu inkluzivas kontroli la veran nomon de ies sur registara identigilo.
Do Debian ne estas sekura kontraŭ ĉi tia afero... sed ĝi prenis raciajn paŝojn. Se vi aldonas triajn deponejojn, vi malfortigas tiun sekurecon. Do kiel mi diris: Homoj devas esti singardaj de kie ili ricevas sian programaron.
Estingi la fajron
La respondo de Canonical al la okazaĵo (kovrita en la video) estas ke kriptaj programoj (kaj nur kriptaj programoj) nun provizore trapasos revizion. Ĉi tio faras nenion pri ĉiuj aliaj programoj, kiuj povas legi viajn hejmajn dosierojn.
Plue, komento de @alexhajnal107 tekstas: 06:04 La nova sistemo kiel priskribita ankoraŭ estas misa. Kun ilia nova sistemo oni povus alŝuti pirata sed senŝanĝan version de programo. Ĉar ĝi ne estas malica ĝi povas bone trapasi revizion. Atendu ĝis ĝi ricevas amason da instaloj kaj alŝutu malican ĝisdatigon. Laŭ ilia deklarita politiko ĉi tio ne estos reviziita.
Tamen, la politiko de Ubuntu devigi ĝisdatigitajn versiojn al uzantoj efektive helpas ilin forigi la malbonan-programon de la komputiloj de homoj. Ili simple kreis pli novan version de la tuŝitaj pakaĵoj sen programaro ene. Kiom mi povas diri, estas alie neniu mekanismo por eĉ lasi homojn scii kio okazas.
Je 9 minutoj en la video ni ekscias, ke tre simila okazaĵo jam okazis en majo 2018. Tio estas antaŭ 5 jaroj - en la tuta tempo, praktikoj ŝajnas tute ne pliboniĝi. Kial ili pliboniĝus ĉi-foje?
Lecionoj por ni
Ĉi tiu okazaĵo estas la fina ŝtono sur la tombo de la projekto Snap de Ubuntu, kiom mi koncernas. Kiu uzas bildpakaĵojn, nun provu kompreni la riskojn kaj serĉu alternativojn. Sed la ĝenerala publiko hodiaŭ ial malfacilas lerni certajn lecionojn.
Fido je la programarpakaĵoj estas la plej grava servo provizita de Linukso-distribuo. Forgesante ĉi tion, Ubuntu meritas ilian daŭran perdon de publiko - kaj ekzistas multaj alternativoj tie.
Kiam mi uzas Linukson, nomu min freneza, sed... mi volas, ke pluraj homoj aprobis la programaron, kiun mi funkcias. Pro tio verŝajne la sendanka laboro de pakado de programaro meritas eĉ pli da dankon ol ni sciis.
Ĉi tio okazis al Snap, sed mi ne scias ĉu FlatHub havas malsamajn politikojn.
Kaj se vi uzas proprietan programaron, vi finfine ne havas ideon, kion ĝi faras en via maŝino, ĉar neniu havas aliron al la fontkodo, kaj la binaroj estas neesploreblaj. Neniu granda teknologia kompanio nuntempe meritas esti fidinda, ĉar ili ĉiuj spionas nin kaj kolektas faktojn pri ni kaj konstruas eĉ ombrajn profilojn pri ni. Se mi sonas paranoja al vi, pardonu, la vero estas ke vi estas nur malbone informita.
Nix kiel bona komplemento
La ĉefa problemo kun bildpakaĵoj estas sekureco; estas multe pli facile revizii kaj fidi ununuran pakaĵmanaĝeron en kiu dependecoj estas reuzataj. Kiam dependecoj estas inkluzivitaj en bildo, vi devas fidi la bildon, do la laboro ne nur triobligas aŭ kvarobligas, ne -- la laboro estas multobligita per la nombro da bildoj kiujn vi uzas, oble la nombro da versioj en tempo.
Jen unu el la kialoj, kial mi uzas nix kiel duan pakaĵadministrilon por kompletigi la ĉefan en distribuo. Mi povas trovi ĉiujn programojn, kiujn mi bezonas en aŭ apt aŭ nix. Tio estas pli bona ol uzi bildpakaĵojn.
NixOS estas Linukso-distribuo bazita sur la pakaĵmanaĝero nix, kiu havas bonegajn funkciojn por sekurecaj revizioj. nix generas identigon (vere haŝon) por ĉiu pakaĵo, surbaze de ĝia fontkodo interalie. Se la binaro ne plu disponeblas ial, nix konas la git commit kaj la adreson de kiu akiri la fontkodon, kaj tuj elŝutas la fontkodon, kompilu ĝin sur via maŝino kaj produktas la bit-post-bitan ĝustan saman pakon, kies binaro estis perdita en tempo. Mi ankoraŭ lernas pri nix sed mi vetus, ke ĝi estas la plej bona afero por sekureco.