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
Ehemaliger
Anmeldungsdatum: Beiträge: 29041 Wohnort: WW |
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 |
Anmeldungsdatum: Beiträge: 454 |
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:
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
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:
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 |
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
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. |
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
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.
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.
Auch ein guter Einwand. |
Ehemaliger
Anmeldungsdatum: Beiträge: 29041 Wohnort: WW |
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.
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 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 |
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
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. |
Ehemaliger
Anmeldungsdatum: Beiträge: 29041 Wohnort: WW |
Hallo,
Ja... und weiter? Was ist die Konsequenz daraus für das System oder dich als Anwender? Gruß, noisefloor |
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
"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." 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.
|
Anmeldungsdatum: Beiträge: 3035 Wohnort: Köln |
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.
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. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 864 Wohnort: Pfalz |
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: Hinweis!Fremdsoftware kann das System gefährden. Anmerkung: Diese Installation über snap kann einen höheren Speicherbedarf verursachen (ggf. näher angeben: snap: ~ 286MB; als .deb: ~ 30MB) (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. |
(Themenstarter)
Anmeldungsdatum: Beiträge: 864 Wohnort: Pfalz |
Hi noisefloor,
Ich habe versucht, das im Artikel zu integrieren, gerne ergänzen o.Ä., falls euch das niht gefällt. LG |
Anmeldungsdatum: Beiträge: 454 |
Hallo UlfZibis,
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.
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 |
Anmeldungsdatum: Beiträge: 454 |
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 |
(Themenstarter)
Anmeldungsdatum: Beiträge: 864 Wohnort: Pfalz |
Ja stimmt, am besten werde ich künftig vorher sudo apt-get update && sudo apt-get install PAKET df -m
und nach der Installation Nachtrag: Ist auch nicht optimal, da der Snap-Store nicht berücksichtigt wird, ebenso wenig wie doppelte oder mehrfache Snap-instanzen des gleichen Pakets... |
(Themenstarter)
Anmeldungsdatum: Beiträge: 864 Wohnort: Pfalz |
noisefloor schrieb: ...
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 Oder, ist es prinzipiell etwas sicherer snaps, wenn man sie nutzen möchte, lieber als – classic zu installieren?
LG |