> Ha az apt-nek van security szempontból problémája, az nem más, mint a bizalom a maintainerekben.
Is, nyilván, de nem egészen. A probléma azzal van, hogy milyen granualitással kell megbízni egy "kulcsban" (repóban, ahogy tetszik). Az aptben -- és egyébként a legtöbb tradicionális disztró csomagkezelőben is, ebben teljesen igazad van -- kb mindent visz egy ilyen. És ez teljesen jogos volt addig, amíg arra voltak használva, amire tervezték őket: hogy a disztró tegye bele a dolgokat, hiszen bennük már egyébként is bízunk, nincs szükség részletesebb kontrollra. Arra viszont emiatt nem nagyon jók, hogy third partyt repót hozzáadjunk, hogy kényelmesen telepíthető legyen, úgy, hogy a bizalom csak ezekre a csomagokra legyen érvényes. És ez bizony, egy technikai probléma. Ha ez nem lenne, akkor a maintainer nyugodtan odatehetné a vscode repot, hogy aki akarja, az könnyen telepíthetné a vscodeot, a többiek meg nem veszély nélkül leszarhatnák. (Igen, az adatporszívót is egy egyszerű első letöltés előtt kérdezünk metódus beépítésével is lehetne kontrollálni).
Ilyet persze nem egyszerű csinálni, egy csomó korlátozással jár, ha telibe akarod tolni, de ez nem jelenti azt, hogy ez ettől nem security probléma az aptben (rpmben, pacmanban, akármiben). Mert azért lássuk be, hogy ma már a külső csomagok telepítése egy teljesen jogos igény.
Ezzel együtt azért lehetne egy csomó dolgot csinálni:
- lehetne erősen javítani a default viselkedésen (tudom, tudom, attól még át lehet kapcsolni, de ebben a konkrét esetben szerintem a maintainer tudatlansága is benne volt, nem direkt rosszindulat)
- lehetne az egész transzparenciáján javítani, hogy a user jobban lássa, mi honnan jön (ez pl rpmben jobb)
- a mindenféle jóváhagyás szükségességét bele lehet tolni magába a toolba, hogy kérdezzen a usertől mindenképp, akár első kulcshasználat, akár első letöltés előtt
- Lehetne a csomagok tartalmát alapból pinnelni az első repohoz, amiből letöltődtek
- Lehetne a külsős tárolókat kontrollálni, akár abban, hogy milyen csomagokhoz nyúlhatnak, akár abban, hogy hova írhatnak, mit futtathatnak
- mert pl egyáltalán nem muszáj ám az, hogy "telepítőscriptjei root joggal futnak".
- Sem egyáltalán a telepítő script: lehetne az egész folyamat deklaratív. Az aptnak egyébként is szerintem az egyik legnagyobb rákfenéje épp az, amit egy csomóan szeretnek benne, a mindenféle pre/postinst támogatás, meg user kérdezgetés beállításokról. Emlékszem, nekem is furi volt, mikor először rájöttem, hogy pl az rpm ebből a szempontból sokkal ergyább, de aztán végiggondolva rá kellett jönnöm, hogy bár rém kényelmesnek tűnik, igazából összekeveri a telepítést a konfigurálással, és ez hosszú távon mindenféle bajhoz vezet, jobb az, ha egyszerűbb.
- Sem a root jog. Lehetne azt is izolálni valahogy
- Mert hogy bizony lehetne izolálni. Akár a telepítés folyamata közben (vagyis pl garázdálkodhat ugyan, de mondjuk csak egy overlayen, aminek a mergejét ellenőrizzük, vagy csak bizonyos selinux/apparmor kontextusban root nélkül, vagy fene tudja)
- Akár a telepítés célját tekintve. Bizony, kaphat mindenki saját homokozót (lásd pl snap), aztán azon belül úgy baszhat ki önmagával, ahogy akar, vagy lehet használni a flatpack modelljét, lehet konténeres izoláció (szerűt) játszani, ott a cgroups, ott a selinux, ott vannak a mindenféle namespacek a kernelben, kaphat dedikált írásterületet, nem kötelező ám pl írni tudni a /usr-t.
> Ha bármelyik disztribúció úgy dönt, hogy iltt bizonyos elveket leszarnak, akkor a disztribúció használói vagy elfogadják, vagy menekülnek.
Ez természetesen igaz, de a tooling azért sokat segíthetne nekik, hogy a jogos igényeiket könnyebben tudják jól kivitelezni. És sokat segítene a usereknek, hogy látszon, ha ezekkel a maintainer explict baszkodik, hogy márpedig ő ezt nem így akarja csinálni, aztán ha ez nem tetszik, tudjon menekülni.