staging.inyokaproject.org

Hallo,

bzgl. der Warnung: Es ist jetzt so im Artikel zu Textbausteinen dokumentiert.

Wer stellen im Wiki findet, so das bei snap, flatpak, Appimage & Co fehlt, kann die Fremdsoftware-Warnung gerne einbauen.

Gruß, noisefloor

Hallo,

ich habe mich in der letzten Zeit aus Neugier über das Konzept/Vor-/Nachteile etwas in das Thema Snaps eingelesen.

Bei der Aussage hier im Thread:

tomtomtom schrieb:

Snaps sind genau das: Vollkommen ungeprüfte Fremdquellen.

mußte ich stutzen, da mir das nach dem, was ich über Snaps weiß, in dieser pauschalen Form nicht zuzutreffen scheint.

Daher habe ich hier mal die Punkte zusammengefaßt, bei denen ich Vorteile von Snaps gegenüber unbekannten Fremd-PPAs sehe. Einiges davon hat auch noisefloor schon angedeutet.

Unterschiede/Vorteile Snaps ggü. Fremd-PPAs

• Nicht jede Person kann einfach Snaps mit beliebigen Namen hochladen. Wenn die Upstream-Entwickler_innen Snaps der eigenen Software pflegen, können nur diese neue Versionen eines Snaps mit dem Namen ihrer Software ohne Zusätze (z.B. firefox vs. firefox-von-anna, vlc vs. vlc-bernhards-version etc.) onlinestellen. Wenn die Upstream-Maintainer (noch) keine Snaps erstellen und trotzdem Drittpersonen Snaps von entsprechender Software erstellen und hochladen wollen, wird der Name und die zugehörigen Snaps von den Snapcraftern verwaltet (und den Upstream-Entwicklern übergeben, wenn diese selbst für ihre Software Snaps erstellen wollen). Quelle: https://snapcraft.io/docs/registering-your-app-name

• Es gibt beim Hochladen zumindest automatische Reviews der Snaps (ich weiß allerdings nicht, in welchem Umfang). Quelle: https://snapcraft.io/docs/releasing-your-app

• Snaps laufen standardmäßig abgeschottet und isoliert (Confinement, hierfür gibt es unterschiedliche Confinement Level/Berechtigungslevel). Worauf ein Snap zugreifen darf und worauf nicht, kann recht feingranular konfiguriert werden und vor der Installation eingesehen werden. Diese Zugriffsberechtigungen werden so minimal wie möglich gehalten, also nur soviel, wie das jeweilige Programm tatsächlich zum Funktionieren benötigt. Da haben die Snapcrafter (Leute, die Snaps paketieren) ein Auge drauf. Es gibt auch die Möglichkeit, Snaps mit Classic-Confinement ohne spezielle Zugriffsbeschränkungen auf das restliche System (will heißen: so wie bei Debian-Paketen) auszuliefern, aber das ist nur nach manuellem Review des Snaps und einer guten Begründung möglich (bedeutet: niemand kann einfach so Snaps mit Classic-Confinement in den Store hochladen). Außerdem muß bei der Installation solcher Snaps explizit die Option --classic angegeben werden - daher ist für Benutzer_innen transparent, bei welchen Snaps dies der Fall ist (Details). Für Software in Debian-Paketen (insbesondere auch solche aus Quellen unbekannter Vertrauenswürdigkeit!), existiert nichts von alledem - diese hat Vollzugriff auf das gesamte System!

• Es gibt offiziell von Canonical betreute Snaps (wie Chromium).

• Snaps sind fester Bestandteil der Standardinstallation (z.B. der Snap-Store).

• Konzeptbedingt ist bei Snaps nicht mit Problemen wie ungewünschtes Überschreiben von System-Paketen (Kernel, libc etc.) oder scheiternden Updates durch Abhängigkeitskonflikte bei Dist-Upgrades zu rechnen, die bei Fremdquellen/PPAS auftreten können.

• Es gibt in Snaps keine Maintainer-Skripte, wie sie in Debian-Paketen (ohne irgendeine Warnung!) vorhanden sein können, welche vor/nach der (De-)Installation des jeweiligen Pakets mit Root-Rechten ausgeführt werden und dabei das System beliebig manipulieren können. Siehe dazu auch: https://forum.snapcraft.io/t/why-are-snaps-confined/13842/10

Wenn nun ein Snap von Canonical betreut wird - wo ist dann unter Sicherheitsaspekten ein Unterschied/Nachteil im Vergleich zu den von Canonical betreuten offiziellen Debian-Paketen? Ich sehe erstmal keinen...

Nach meinem Wissen würde ich sagen, selbst bei Snaps von "Dritten" (unbekannte Einzelpersonen ohne Bezug zu der von ihnen als Snap paketierten Software) ist das Gefährdungspotential zu Fremd-PPAs im Vergleich geringer, wegen den oben aufgeführten Punkten wie Confinement und Maintainer-Skripts.

Eine Frage habe ich noch:

tomtomtom schrieb:

Gegen Snaps ist sogar was in PPAs llegt noch unglaublich gut nachvollziehbar...

Welche Punkte meinst Du hier mit "gut/schlecht nachvollziehbar"? Mir scheint es, daß ich über Software aus PPAs und Software aus dem Snapstore auf etwas unterschiedlichen Wegen ziemlich genau dieselben Informationen bekomme...

Viele Grüße, Jan

Speedy-10 schrieb:

Achtung!

Hinweis! Zusätzliche, mit snap, flatpak etc. installierte Software, kann das System gefährden - vergleichbar mit Paketen aus Fremdquellen (ggf. + link zu Erläuterungen) und hat in der Regel hohen Speicherbedarf.

Ich ergänze das, weil z.B. das Programm Delta.Chat per flatpak ~ 1 GB braucht, als DEB-Paket aber nur ~ 70 MB. In dem Fall ist m.E. sogar das Fremdpaket als sicherer zu betrachten als aus flatpak, da es eben nicht diese Menge an potentiell ggü. den Quellen "abgeändertem" Code mitbringt.

noisefloor schrieb:

... sondern die Art und Weise, wie Canonical das handhabt. Und darauf habe selbst ich als Teamleiter Wikiteam keinen Einfluss 😉

Nicht direkt. Aber genauso wie im Fall der früher automatisch installierten Amazon-Suche haben wir doch die Möglichkeit, auf diesen Umstand und deren "Nebenwirkungen" deutlich hinzuweisen inklusive, wie man darum herum kommt.

Grundsätzlich: wenn jemand snaps voll daneben findet, muss es halt eine Distro nehmen, die snaps nicht kennt.

Das finde ich aber jetzt "Das Kind mit dem Bade ausschütten", denn dann könnte man auch sagen, wem Firefox nicht gefällt, der muss um sämtliche Distros, wo man Firefox installieren kann, eine Bogen machen.

Ansonsten stimme ich der Argumentation von tomtomtom zu.

ChickenLipsRfun2eat schrieb:

noisefloor schrieb:

..., weil sie dazu erzogen werden.

Auch ein guter Einwand.

Hallo,

so pauschalisierte Aussagen wie "hat in der Regel einen hohen Speicherbedarf" kommen definitiv ins Wiki. Außerdem schreiben wir das Jahr 2020 und nicht 1990... sprich: Speicherplatz ist vergleichsweise billig und kein kostbares gut mehr.

Außerdem: wenn du deine Software alleine nach dem Platzbedarf auswählst und nicht nach den Features, die die brauchst, dann hast du... sagen wir mal Auswahlkriterien, die ich nicht gerade als "repräsentativ" bezeichnen würde.

Wenn nun ein Snap von Canonical betreut wird - wo ist dann unter Sicherheitsaspekten ein Unterschied/Nachteil im Vergleich zu den von Canonical betreuten offiziellen Debian-Paketen? Ich sehe erstmal keinen...

Prinzipiell richtig. Ich würde das auch auf Software erweitern, die vom Entwickler selber "gesnapt" werden. Wie z.B. VS Code von Microsoft. Nur ist das halt nicht immer so einfach ersichtlich, weil der Entwickler ja nicht immer so "prominent" ist. Z.B. wird das snap zum Editor Micro auch vom Entwickler bereitgestellt, aber bei Herausgeber beim snap steht zy - was ziemlich nichtssagend ist. Also so pauschal kann man vom Bereitsteller des snaps nicht unbedingt was "gutes" oder "schlechtes" ableiten.

Bzgl. "Es gibt beim Hochladen zumindest automatische Reviews der Snaps": das verhält sich bei snaps halt wie bei Installation aus dem Google Playstore oder dem Apple App Store oder Python Wheels von PyPi oder Modulen via npm: ein gewisses Grundvertrauen, dass der Betreiber seine Plattform "sauber" hält, sollte vorhanden sein.

Gruß, noisefloor

Gruß, noisefloor

KaiserClaudius schrieb:

• Konzeptbedingt ist bei Snaps nicht mit Problemen wie ungewünschtes Überschreiben von System-Paketen (Kernel, libc etc.) oder scheiternden Updates durch Abhängigkeitskonflikte bei Dist-Upgrades zu rechnen, die bei Fremdquellen/PPAS auftreten können.

• Es gibt in Snaps keine Maintainer-Skripte, wie sie in Debian-Paketen (ohne irgendeine Warnung!) vorhanden sein können, welche vor/nach der (De-)Installation des jeweiligen Pakets mit Root-Rechten ausgeführt werden und dabei das System beliebig manipulieren können. Siehe dazu auch: https://forum.snapcraft.io/t/why-are-snaps-confined/13842/10

Das ist zwar richtig, doch es bleibt ein Problem: Es werden zwar keine System-Pakete direkt manipuliert, aber snaps können die Nutzung von gut geprüften System-Paketen umgehen, in dem sie eigene "manipulierte" Varianten mitbringen, die dann bei der Nutzung dieser Software zum tragen kommen.

Hallo,

aber snaps können die Nutzung von gut geprüften System-Paketen umgehen, in dem sie eigene "manipulierte" Varianten mitbringen, die dann bei der Nutzung dieser Software zum tragen kommen.

Ja... und weiter? Was ist die Konsequenz daraus für das System oder dich als Anwender?

Gruß, noisefloor

noisefloor schrieb:

so pauschalisierte Aussagen wie "hat in der Regel einen hohen Speicherbedarf" kommen definitiv ins Wiki. Außerdem schreiben wir das Jahr 2020 und nicht 1990... sprich: Speicherplatz ist vergleichsweise billig und kein kostbares gut mehr.

"in der Regel" ist vielleicht etwas hoch gegriffen und kann durch "in vielen Fällen" oä ersetzt werden.

Ich werde oft mit der Frage konfrontiert: "Mein Rechner ist lahm geworden, kannst Du da was machen, oder muss ich einen neuen kaufen."
Klar kann ich da was machen, ich installiere da Ubuntu und der Nutzer erfreut sich seiner etwas älteren Hardware noch über Jahre. In dem Fall ist der Speicherbedarf ein wichtiges Kriterium.
Die Umgewöhnung von Windoof auf Ubuntu ist auch für Laien-Nutzer meist kein Problem, wenn sie mit dem Ding eh nur Surfen, Chatten und E-Mails schreiben, auch die Umstellung von M$-Office auf Libre-Office.

Was den Platten-Platz angeht, sind 2..4 überflüssige GB tatsächlich selten ein echtes Problem, doch im RAM kann es da schon ziemlich eng werden, denn etwas ältere "Reise-Rechner" (z.B. Net-Books) haben oft nur 1..2 GB RAM die nicht erweitert werden können. Da ist es dann schon "blöd", wenn ein lausiges per snap oder flatpack installiertes Chatprogramm dann noch 1 GB zusätzlich beansprucht.

Aber auch auf der Platte kann es ganz schön eng werden, wenn die vorhandene Windowsinstallation zumindest übergangsweise erhalten bleiben soll und die Platte schon einigermaßen voll mit Daten ist. Ein zusätzliches Ubuntu braucht, wenn auf die standardmäßig per Snap installierten GNOME-Pakete verzichtet wird, nur 5..6 GB. Da finde ich 2 + GB mehr für Snap durchaus "signifikant", überflüssig und "asozial" (Neuer Rechner oder auch nur Festplatte bedeutet: Geldproblem für Geringverdiener, Müll, Rohstoff- und Energieverbrauch und letzteres verursacht Kriege und Umweltprobleme). Die Ersparnis an GB kann für die Erweiterung eines Windoof-Rechners mit Ubuntu dann schon mal entscheidend sein, zumindest, wenn es mal eben auf die Schelle eingerichtet werden soll.

noisefloor schrieb:

Ja... und weiter? Was ist die Konsequenz daraus für das System oder dich als Anwender?

• Anwender: Ich werde ungebeten "belauscht" und/oder das ganze System lahmt wegen hohem Ressourcenverbrauch. Beispiel Krypto-Miner.

• System: Potentiell eingebaute Einfallstore für Malware gefährden das System.

UlfZibis schrieb:

Aber auch auf der Platte kann es ganz schön eng werden, wenn die vorhandene Windowsinstallation zumindest übergangsweise erhalten bleiben soll und die Platte schon einigermaßen voll mit Daten ist. Ein zusätzliches Ubuntu braucht, wenn auf die standardmäßig per Snap installierten GNOME-Pakete verzichtet wird, nur 5..6 GB. Da finde ich 2 + GB mehr für Snap durchaus "signifikant", überflüssig und "asozial" (Neuer Rechner oder auch nur Festplatte bedeutet: Geldproblem für Geringverdiener, Müll, Rohstoff- und Energieverbrauch und letzteres verursacht Kriege und Umweltprobleme). Die Ersparnis an GB kann für die Erweiterung eines Windoof-Rechners mit Ubuntu dann schon mal entscheidend sein, zumindest, wenn es mal eben auf die Schelle eingerichtet werden soll.

Ich kenne auch einige, denen wegen einem Festplattenschaden dann als Ersatz eine knappe 80-GB-SSD (mehr war bis vor kurzem nicht gerade billig) verkauft wurde. Da wird es dann richtig knapp.

noisefloor schrieb:

so pauschalisierte Aussagen wie "hat in der Regel einen hohen Speicherbedarf" kommen definitiv ins Wiki.

Und was kann man gegen "pauschalisierte Aussagen" tun? ... Vielleicht ein Verbesserungsvorschlag?

Das Speicherplatzproblem deshalb ganz zu unterschlagen, finde ich jedenfalls auch keine Lösung.

EDIT: Und außerdem: Warum waren denn bisher pauschalisierte Aussagen erlaubt? Z.B.: Fremdsoftware kann das System gefährden.
Also mein Verbesserungsvorschlag:

Hi zusammen, eigentlich finde ich den letzten Vorschlag von UlfZibis am besten, verstehe aber auch den Wunsch, die Textbausteine möglichst einheitlich zu halten (noisefloor).

Wenn man (als Autor und falls davon überzeugt) die weitere Infos von UlfZibis in den Kommentar packt, dann hätten wir einen Kompromiss:

(Die Zahlen waren jetzt für gnome-calculator aus dem Gedächtnis von Hr Kofler.)

Dann kann der user aufgrund genauerer Angaben selbst entscheiden.

Übrigens finde ich 2 - 4 GB mehr Speicher auch problematisch, da ich stets favorisiere / als eigene Partition mit ca. 15-20 GB anzulegen, dann kann das System auch an seine Grenzen kommen.

LG

PS: Wenn ich die Installationsgröße bei Snap aus dem Snap-Store nehme und bei einer anderen Installation, z.B. apt-cache show spotify-client aus "Size: 114975574", dann sollte das ein objektiver Vergleich sein, gerundet auf ganze MB.

Hi noisefloor,

Richtig. Das ist halt die Designentscheidung von Canonical. Darauf kann man gerne auch im passenden Artikel hier im Wiki hinweisen. Und das ist auch kein Problem von snap als Paketformat, sondern die Art und Weise, wie Canonical das handhabt. Und darauf habe selbst ich als Teamleiter Wikiteam keinen Einfluss 😉 Das gleiche gilt doch auch, wenn man sich das flatpak-plugin für Gnome-Software installiert.

Ich habe versucht, das im Artikel zu integrieren, gerne ergänzen o.Ä., falls euch das niht gefällt. LG

Hallo UlfZibis,

UlfZibis schrieb:

KaiserClaudius schrieb:

• Konzeptbedingt ist bei Snaps nicht mit Problemen wie ungewünschtes Überschreiben von System-Paketen (Kernel, libc etc.) oder scheiternden Updates durch Abhängigkeitskonflikte bei Dist-Upgrades zu rechnen, die bei Fremdquellen/PPAS auftreten können.

• Es gibt in Snaps keine Maintainer-Skripte, wie sie in Debian-Paketen (ohne irgendeine Warnung!) vorhanden sein können, welche vor/nach der (De-)Installation des jeweiligen Pakets mit Root-Rechten ausgeführt werden und dabei das System beliebig manipulieren können. Siehe dazu auch: https://forum.snapcraft.io/t/why-are-snaps-confined/13842/10

Das ist zwar richtig, doch es bleibt ein Problem: Es werden zwar keine System-Pakete direkt manipuliert, aber snaps können die Nutzung von gut geprüften System-Paketen umgehen, in dem sie eigene "manipulierte" Varianten mitbringen, die dann bei der Nutzung dieser Software zum tragen kommen.

Ich kann jetzt spontan nicht sagen, ob und wie leicht dieses Szenario bei Snaps möglich wäre, aber wenn, dann ist dies kein "neues" Problem von Snaps ggü. Debian-Paketen. Wenn eine Person tatsächlich einem Paket manipulierte Systembestandteile wie Bibliotheken etc. unterschieben will, ginge das in Debian-Paketen genauso und noch besser als bei Snaps. Der Inhalt der Debian-Pakete läuft noch nicht mal in einer Sandbox!

Für relevanter bezüglich der Sicherheit von Snaps halte ich die Frage, ob und wie zeitnah in den individuellen Snaps gebundelte Bibliotheken mit Sicherheitsupdates versorgt werden. Falls dies nicht geschieht, soll ja die Sandbox (Confinement) verhindern, daß Malware im Fall eines Angriffs auf das ganze restliche System zugreifen kann. Aber alles kann die Sandbox auch nicht verhindern, z.B. wenn ein betroffener Snap z.B. Zugriffsrechte auf die persönlichen Daten im home-Verzeichnis hat. Dementsprechend scheint es mir keine schlechte Idee zu sein, bei gesnappten Programmen mit regelmäßiger Internetkonnektivität auch immer mal zu schauen, ob und wie regelmäßig die im Snap enthaltenen Bibliotheken mit Sicherheitsupdates versorgt werden.

UlfZibis schrieb

Ich ergänze das, weil z.B. das Programm Delta.Chat per flatpak ~ 1 GB braucht, als DEB-Paket aber nur ~ 70 MB. In dem Fall ist m.E. sogar das Fremdpaket als sicherer zu betrachten als aus flatpak, da es eben nicht diese Menge an potentiell ggü. den Quellen "abgeändertem" Code mitbringt.

Die Überlegung "Größeres Paket = höheres Sicherheitsrisiko" scheint mir allenfalls bezogen auf obiges Problem mit gebundelten Bibliotheken nachvollziehbar (je mehr an Bibliotheken mitgeliefert wird, desto mehr mögliche Einfallstore bei Nachlässigkeit mit Sicherheitsupdates). Aber nicht, wenn es um die Frage geht, ob jemand ins Paket selbst Malware gepackt hat. Auch Schadcode, der wirklich üble Dinge auf dem System machen kann, wird in der Regel nicht besonders "groß" sein (also insbesondere nicht so groß, daß es sofort auffällt)...

Wegen dem Speicherplatzbedarf von Snaps: Vielleicht habe ich bei Gelegenheit mal Lust, zwei Testsysteme/VMs aufzusetzen, bei denen ich eine Reihe von gängigen Programmen einmal aus dem normalen Repository und einmal als Snaps installiere, und gucke dabei, wie unterschiedlich der Gesamtspeicherverbrauch dann tatsächlich ist. (Ich habe den Verdacht, er könnte gar nicht so hoch sein, wie allgemein angenommen. Bzw. nicht für jeden Snap deutlich höher als die Debian-Paket-Version.)

Viele Grüße, Jan

Speedy-10

PS: Wenn ich die Installationsgröße bei Snap aus dem Snap-Store nehme und bei einer anderen Installation, z.B. apt-cache show spotify-client aus "Size: 114975574", dann sollte das ein objektiver Vergleich sein, gerundet auf ganze MB.

Du hast entsprechende Abhängigkeiten dabei auch mitberücksichtigt? Sonst wäre dies ein irreführender Vergleich, da diese auch Speicherplatz benötigen und ggf. auf dem Zielsystem auch erst installiert werden müssen...

Viele Grüße, Jan

Ja stimmt, am besten werde ich künftig vorher

sudo apt-get update && sudo apt-get install PAKET
df -m

und nach der Installation df -m durchführen.

Nachtrag: Ist auch nicht optimal, da der Snap-Store nicht berücksichtigt wird, ebenso wenig wie doppelte oder mehrfache Snap-instanzen des gleichen Pakets...

noisefloor schrieb: ...

Wobei das ja nur funktionieren würde, wenn man im --classic Modus installiert. snaps, die den Classic-Modus voraussetzen, werden lt. Doku manuell von einem Menschen reviewt. Von daher sollte das wohl nicht passieren können.

Hi, ich muss nochmal nachfragen, um das besser zu verstehen, denn in der o.g. doku steht: "classic which allows the snap to run without restrictions."

Heißt das nun, dass per --classic installierte Pakete keine Restriktionen haben, also mehr Rechte?

Oder, ist es prinzipiell etwas sicherer snaps, wenn man sie nutzen möchte, lieber als – classic zu installieren?

the review process in the snap store will flag for human review snaps that specify classic confinement

the store provides a mechanism for the reviewer to allow classic confinement to the snap so that subsequent uploads do not trigger human review

the publisher shall be vetted using the processes in this topic before classic confinement is granted by the store

LG